第一部分：AI 提效

1.1 输入质量决定输出质量

核心发现：输入从 60 分提升到 80 分，输出从 40 分跳到 85 分——非线性关系。

Demo：模糊指令 vs 精确指令

❌ 模糊指令（60 分输入）：
帮我在规则详情的人员类型中新增两个被执行人人员、被执行人人员指标
​
✅ 精确指令（80 分输入）：
实现规则详情新增接口：/approvalNew/getUserConfigList
新增两个字段：
personnelExecuted   被执行人人员
personnelDishonest  失信被执行人，
数据结构为：
{
    "personRiskList": [
        {
            "name": "刘延峰",
            "relation": "受益所有人",
            "content": "累计人员限制高消费：343次"
        },
        {
            "name": "贾跃亭",
            "relation": "实际控制人、受益所有人、自然人股东",
            "content": "累计人员限制高消费：2次"
        }
    ]
}
下拉多选列表复用组件rule-group-dropdown。

效果差异：模糊指令产出通用代码（缺少复用组件、可能引入不必要的依赖）；精确指令直接产出生产级代码。

三层分工模型

层级	内容	负责方	示例
第一层	产品边界、架构决策、技术取舍	你做	是否引用外部依赖，还是复用已有组件？
第二层	业务代码、接口、页面、测试	AI 做你验收	CRUD、组件
第三层	格式化、样板代码、脚本	AI 全权处理	Makefile、启动脚本、简单重构

精力分配从传统的「20% 核心工作 + 80% 琐碎」变为「60% 核心决策 + 25% 验收 + 15% 其他」。

---

1.2 UI 设计

Demo："看-描述-修" 迭代模式

❌ 直接复制需求文档要求
​
✅ Delta 描述：
当前轮询间隔 1000ms，改成 800ms，其他不变。
列表摘要显示完整内容，改为最多 30 字符 + 省略号。
禁用按钮现在是红色，改成灰色——禁用 ≠ 危险。

核心原则：每次只改一个维度，说清楚「原来是什么 → 改成什么」。5-6 轮迭代即可从粗糙变精致。

---

1.3 技术选型领域四问：传统 2+ 天 → AI 辅助 1 小时咨询 + 2.5 小时执行 = 半天。

Demo：技术选型领域四问

## Step 1 — 是什么（定位）
- 这个技术/方案解决什么问题？
- 和我们当前的方案相比，核心差异是什么？
- 什么情况下不需要它？
​
> 产出：一句话定位 + 适用/不适用场景
​
## Step 2 — 用在哪（场景匹配）
- 结合用户描述的业务场景，分析是否匹配
- 列出核心痛点和该方案的对应能力
- 如果有更简单的替代方案，主动提出
​
> 产出：场景匹配度判断 + 替代方案对比
​
## Step 3 — 由什么组成（工作量评估）
- 引入该方案需要哪些改动？
- 哪些是必须做的，哪些是可选增强？
- 对现有代码的侵入程度如何？
​
> 产出：功能清单（标注优先级和工作量）
​
## Step 4 — 技术架构（落地方案）
- 具体用什么库/工具？
- 目录结构怎么组织？
- 给出最小可运行的代码示例
​
> ⚠ 等待用户确认：技术方案确认后再进入实现阶段
​
> 产出：技术选型结论 + POC 代码

Demo：领域四问法快速建立认知

问题	目的
它是什么，解决什么问题？	建立认知框架
用在哪里，什么场景？	理解优先级
由什么组成？	支撑功能取舍
技术架构？	支撑架构决策

第二部分：AI 踩坑

2.1 指令层踩坑：一次性描述 = 必翻车

Demo：流式聊天的错误提示词

❌ 一次性大段描述：
帮我做一个 AI 对话页面，左边是会话列表，右边是聊天窗口，支持流式回复，
用户消息靠右，AI 消息靠左，底部有输入框，按 Enter 发送，要有打字机效果，
支持 Markdown 渲染，自动滚动到底部。

结果：

• 布局大致对

• 打字机效果是假的（setTimeout 模拟，不是真流式）

• SSE 用了只支持 GET 的 EventSource 发 POST 请求

• Markdown 渲染用了错误的库

  根因：需求混在一起，AI 无法区分优先级，选了「看起来像」的实现方式。

解决方案：分层分解出奇迹

三层分解法：结构层+行为层+细节层

## Step 1 结构层（先对齐布局）：
"看这张草图，描述你理解的页面布局，不要写代码。"
→ 确认理解一致后再继续
​
## Step 2 行为层（时间线描述）：
1. 用户点击发送
2. 输入框清空，发送按钮变 loading
3. 用户消息气泡出现在右侧
4. AI 消息气泡出现在左侧（空白，带闪烁光标）
5. 前端 api/chat/stream，读取 SSE 流
6. 每收到一个 delta，追加到 Markdown 实时渲染
7. 收到 [DONE] 信号，光标消失，按钮恢复
8. 如果中途 error，显示错误提示，按钮恢复
​
## Step 3 细节层（delta 微调）：
"打字机间隔从 50ms 改成 30ms，其他不变。"

---

2.3 AI 行为特性踩坑

改动扩散

❌ 让改 前端数据结构，Claude Code "顺便" 改了 中间层 数据参数
​
✅ 显式约束：
"不要修改流式调用、中间层转发、数据存储的逻辑。不要改Service层和Api层。"

边界条件大概率遗漏（工作流引擎）

Claude Code 正常路径写得好，但以下边界大概率漏掉：

1. 条件分支所有条件都不匹配 → 默认走哪？

2. 空数据

3. 超长宽度、超大数据

4. 无中间状态反馈，用户以为卡死

   应对：AI 写完正常路径后，专门追问边界情况。

   应对：接受「首次 70 分」，用迭代代替追求完美。

---

第三部分：AI 建议

咨询类：领域四问

# 模板1：技术调研
  领域分析：
    [领域] 要支持 [功能]。帮我分析：主流方案有哪些？共性和差异？各有什么限制？
  依赖评估：
    [语言] 生态里有没有封装了 [能力] 的库？对比下利弊，我的场景是 [约束]。
  数据模型设计:
    基于上面的分析，设计 [模块] 的数据模型。要求：[具体约束1]、[约束2]、[约束3]。

实现类

# 模板2：约束驱动实现
修改 [Class] 的 [method] 方法，[具体改动]。
改动范围：只改 [method] 这一个方法。
不要修改 [A]、[B]、[C] 的逻辑。不要改 [Layer] 层。

调研类

# 模板3：技术方案调研
[问题域] 在业界有哪些主流实现方案？重点看 [平台1]、[平台2]、[平台3]。
我想了解：[维度1]、[维度2]、[维度3]、[维度4]。
最后给我建议：[项目] 这种体量应该选哪种方案，为什么。

调整类

# 模板4：Delta 微调
当前 [现状描述]，改成 [目标描述]，其他不变。