文章目录
-
- 前言
- [一、为什么别一上来就问"哪个 AI 强"](#一、为什么别一上来就问“哪个 AI 强”)
-
- [1.1 工具是放大器，不是复活甲](#1.1 工具是放大器，不是复活甲)
- [1.2 一句经典提问，坑的含量接近满分](#1.2 一句经典提问，坑的含量接近满分)
- [1.3 先认清这四个问题](#1.3 先认清这四个问题)
- 二、一条开发工作流到底长啥样
-
- [2.1 从需求到交付，一共七站路](#2.1 从需求到交付，一共七站路)
- [2.2 别只在一个站台等车](#2.2 别只在一个站台等车)
- [三、重点盘这 5 个节点](#三、重点盘这 5 个节点)
-
- [3.1 需求到任务：边写边猜是病，得治](#3.1 需求到任务：边写边猜是病，得治)
- [3.2 阅读代码：你是在写代码，还是在考古](#3.2 阅读代码：你是在写代码，还是在考古)
- [3.3 方案到实现：别让 AI 一口气把饭喂完](#3.3 方案到实现：别让 AI 一口气把饭喂完)
- [3.4 测试排障：AI 要的是证据，不是情绪](#3.4 测试排障：AI 要的是证据，不是情绪)
- [3.5 交付复盘：别让经验烂在聊天记录里](#3.5 交付复盘：别让经验烂在聊天记录里)
- [四、盘点完了，AI 先放哪](#四、盘点完了，AI 先放哪)
-
- [4.1 挑节点的三个条件](#4.1 挑节点的三个条件)
- [4.2 推荐的起步顺序](#4.2 推荐的起步顺序)
- 五、今天就能做完的一次盘点
-
- [5.1 六步走，不需要仪式感](#5.1 六步走，不需要仪式感)
- [5.2 现成清单，直接抄](#5.2 现成清单，直接抄)
- 六、总结
P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/H1727548
前言
过去三个月，我换了五个 AI 工具，比换衣服还勤。结果你猜怎么着？需求该猜还是猜，Bug 该返工还是返工，唯一的收获是我对各家模型的定价倒背如流------不知道的以为我在做市场调研，知道的都明白，我只是在逃避一个问题：我的开发流程，本来就乱成一锅粥。
先别急着问"哪个 AI 写代码最强"。流程没盘清楚就问这个，等于没考驾照先问哪款车跑得快------先来的不是答案，是事故。
一、为什么别一上来就问"哪个 AI 强"
1.1 工具是放大器，不是复活甲
很多人换大模型的心态，跟买新键盘一模一样：装备到位，技术自动到位。醒醒，AI 是放大器，不是复活甲。流程是乱的，放大器只会把乱放大，放大到老板一眼就能看见。
先看看很多人的真实工作方式：
收到需求 ↓ 边问边写 ↓ 出了问题再查 ↓ 临近交付时补测试这不是工作流，这是"先把雷埋好，再亲手踩一遍"的流程图。每一步单独看都合理，连起来就是事故现场。
1.2 一句经典提问，坑的含量接近满分
入行这些年，我听过最经典的一句话是：
帮我实现一个订单金额计算功能。这句话信息量约等于零，坑的含量却接近满分。商品价格合不合法？优惠券能不能超过总价？金额按元存还是按分存？运费、税费、会员折扣算不算？错了是抛异常还是返回业务错误码？逻辑放 Controller 还是领域层？------你让 AI 猜，AI 就敢编；你换十个 AI，就是十个敢编的，区别只是编的姿势不同。
问题没在前面解决，换谁都是赌。有的赌注小一点，有的赌注是上线前的一夜。
1.3 先认清这四个问题
盘流程，重点看四件事：哪个环节最耗时、哪个环节信息最不完整、哪个环节最容易返工、哪个环节结果最好验证。翻译成大白话：哪儿疼、哪儿瞎、哪儿白干、哪儿能验收。
AI 最适合待在"目标清楚、上下文能给、结果能验"的位置，就像好员工得放在能出业绩的岗位------你非把他安排去天天写周报，再强的 AI 也救不了。
二、一条开发工作流到底长啥样
2.1 从需求到交付，一共七站路
一个功能从需求到交付，通常走这条线：
理解需求 ↓ 阅读现有代码与资料 ↓ 设计方案和拆分任务 ↓ 编写与修改代码 ↓ 测试、调试和排错 ↓ 代码审查、联调与发布 ↓ 文档、复盘与知识沉淀七个节点，大多数人的 AI 只在"编写代码"这一站出过勤。这等于买了张全价机票，只坐了机场摆渡车。
2.2 别只在一个站台等车
真正该盘的是：每个节点的输入是什么、产出是什么、常见阻塞是什么、AI 能帮什么、最后谁验收。拿一个正在做的真实任务填张表：
| 工作环节 | 当前在做什么 | 最耗时或最容易卡住的地方 | 可交给 AI 的辅助任务 | 必须人工确认的结果 |
|---|---|---|---|---|
| 需求理解 | 阅读需求、和产品沟通 | 规则不完整、边界遗漏 | 列待确认问题、整理需求清单 | 业务规则和验收标准 |
| 代码阅读 | 找入口、追调用链 | 项目陌生、模块耦合 | 总结目录、解释调用链 | 真实代码路径和影响范围 |
| 方案设计 | 定接口、分模块 | 方案选择多、风险不清 | 比较方案、列风险和测试点 | 架构与业务取舍 |
| 代码实现 | 写模块、改逻辑 | 样板代码多、上下文切换 | 生成草稿、补类型和注释 | 代码质量和项目一致性 |
| 测试排障 | 写测试、查错误 | 边界遗漏、日志分散 | 设计测试矩阵、归类异常 | 根因、修复和回归结果 |
| 交付沉淀 | 提交、写文档、复盘 | 过程没有记录 | 整理变更、生成复盘初稿 | 最终说明和经验结论 |
这张表不是让你把活全外包给 AI，是让你先看见时间和风险藏在哪。就像体检，先看见超标项，才知道该挂哪个科------你总不能拿着血常规报告去找骨科大夫。
三、重点盘这 5 个节点
3.1 需求到任务：边写边猜是病，得治
需求一进来就闷头写，写到一半才发现：字段没定义、状态流转没说清、异常没人讨论、验收标准只存在于产品经理的嘴里。这不是开发，这是蒙眼做菜，好不好吃全看上菜时的运气。
这种时候该让 AI 干的不是写代码，是拆需求：
请协助拆解下面这条需求，但先不要写代码。
需求： [粘贴原始需求]
请输出：
1. 需要确认的业务规则。
2. 正常、边界和异常场景。
3. 可能涉及的接口、数据结构和状态变化。
4. 可以拆分的开发任务。
5. 仍然无法从需求中判断的假设。产出是一份开发前检查清单，不是一段代码。先问清，再动手，别拉着 AI 陪你一起猜。你俩猜得再默契，猜错的锅也不会分着背。
3.2 阅读代码：你是在写代码，还是在考古
接手一个三年没动的旧模块，最耗时的从来不是改代码，是搞清楚：请求从哪个入口进、核心逻辑在哪一层、数据从哪读从哪写、改了会炸谁。你打开那个项目时的心情，跟考古队开棺一模一样------充满期待，又怕里面蹦出个不认识的怪物。
我需要修改一个订单取消功能。
下面是相关目录结构、Controller、Service 和测试文件： [粘贴目录和关键代码]
请输出：
1. 请求入口到数据写入的调用链。
2. 每个文件的职责。
3. 订单状态校验可能出现的位置。
4. 修改功能时可能受影响的调用方。
5. 建议我优先阅读的文件顺序。
不要猜测未提供的代码；不确定的地方请明确标注。AI 给的导览是地图，不是终点。确认调用链还得靠源码搜索、断点、日志和测试四件套。地图能让你少迷路，但路还得自己走------你总不能指望地图替你开车。
3.3 方案到实现：别让 AI 一口气把饭喂完
上来就喊"AI，帮我实现整个功能"的，十有八九会拿到一份"看起来能跑、放进项目就趴窝"的代码。更稳的姿势是拆成三轮：第一轮让 AI 复述任务、列出假设和风险；第二轮比较方案、明确模块边界和测试点；第三轮才按已确认的约束生成最小实现。
订单金额计算，第一轮这么问：
现在需要实现订单金额计算，支持商品总价和优惠券抵扣。
请先不要写代码。
请列出：
1. 需要确认的金额和优惠券规则。
2. 建议的输入、输出和异常策略。
3. 未来接入运费、税费和会员折扣时的扩展点。
4. 可能影响正确性的边界条件。规则确认了，再要函数签名、实现草稿和测试矩阵。方案这一层千万别跳：聊方案只要几分钟，返工能省几小时。这笔账连小学数学都算得明白，可惜大多数人小学数学没学好。
3.4 测试排障：AI 要的是证据，不是情绪
很多人只有出了 Bug 才想起 AI，上来就是一句"为什么报错"。你给 AI 情绪，它只能回你安慰；你给 AI 证据，它才能帮你破案。情绪这东西，连你对象都哄不明白，就别难为模型了。
测试，先列矩阵：
请为下面的订单金额计算规则设计测试矩阵。
规则： [粘贴已确认规则]
请按"正常、边界、异常"三类输出：
- 输入
- 预期结果
- 覆盖规则
- 测试目的
暂时不要生成测试代码。排障，先组织假设：
请协助分析一个接口偶发失败的问题。
已知信息：
- 问题现象：[描述]
- 完整错误栈：[粘贴]
- 最近代码变更：[描述]
- 已排除方向：[描述]
请输出：
1. 按可能性排序的假设。
2. 每个假设需要补充的证据。
3. 最小验证步骤。
4. 不建议直接修改的地方及原因。记住：AI 是帮你出假设、设计验证、找遗漏的，不是替你背锅的。最终结论永远要自己验------锅也永远是你的，这点它跑不掉，你也跑不掉。
3.5 交付复盘：别让经验烂在聊天记录里
任务干完了，所有有用信息都躺在聊天记录里吃灰。三个月后你翻出来一看，里面的需求跟现在一模一样------恭喜，你成功用 AI 把人生复读了一遍。
建议每次高质量协作留四样资产：
| 资产 | 应该记录什么 |
|---|---|
| Prompt 模板 | 任务背景、上下文、约束和输出格式 |
| 规则清单 | 已确认业务规则、边界和验收标准 |
| 测试清单 | 正常、异常和回归场景 |
| 复盘记录 | AI 的有效建议、遗漏点和最终修改原因 |
再来个最小复盘模板：
任务： [本次开发或排障任务]
AI 参与的环节： [需求 / 代码阅读 / 方案 / 实现 / 测试 / 排障 / 文档]
有效做法： [哪些上下文、Prompt 或验证动作最有帮助]
无效或有风险的做法： [AI 漏掉了什么，为什么不能直接采用]
可复用资产： [Prompt、检查清单、测试模板、代码片段]资产攒起来，用 AI 的效率才是稳定输出；不攒，就是偶尔中一次彩票，还是那种五块钱的。
四、盘点完了，AI 先放哪
4.1 挑节点的三个条件
别一上来就全环节改造，先挑一个节点。满足三个条件：重复出现、上下文能给、结果能验。翻译一下：常干的、说得清的、能验收的。三缺一的节点，就像相亲对象说自己"人挺好的"------风险自担，概不退换。
4.2 推荐的起步顺序
对大多数中级开发者，稳妥的顺序是：
需求澄清 ↓ 代码阅读 ↓ 测试矩阵 ↓ 代码审查 ↓ 排障假设整理 ↓ 可控范围内的代码生成为什么从前面开始？因为前面的输出更好审核、风险更低。等路走顺了，再让 AI 碰复杂实现。那时候它才配得上你的信任；在那之前，你那叫一厢情愿。
五、今天就能做完的一次盘点
5.1 六步走，不需要仪式感
不用等什么大项目。等大项目的人，一般都在等下一个大项目。今天挑一个小任务就行：
- 写下任务名称，比如"新增取消订单接口"或"修复优惠券金额计算 Bug"。
- 拆成需求、阅读、方案、实现、测试、交付六个环节。
- 在每个环节标出最耗时、最模糊、最容易返工的地方。
- 只挑一个节点让 AI 参与，记录输入和输出。
- 用测试、代码审查、日志或联调验证结果。
- 把有效的 Prompt 和检查清单存下来。
5.2 现成清单，直接抄
任务名称： [填写]
本次任务经过的环节： [ ] 需求理解 [ ] 代码阅读 [ ] 方案设计 [ ] 代码实现 [ ] 测试排障 [ ] 交付沉淀
最耗时的环节： [填写]
最容易返工的环节： [填写]
本次准备让 AI 参与的一个节点： [填写]
我会提供给 AI 的上下文： [需求 / 代码 / 日志 / 测试 / 规则]
我将如何验证输出： [测试 / 审查 / 联调 / 日志 / 人工确认]
本次要沉淀的资产： [Prompt / 检查清单 / 测试模板 / 复盘]这清单不是给你增加负担的，是给 AI 的使用"转正"的：从临时工提问，变成有目标、有上下文、有验证的正规军。临时工干得好是运气，正规军干得好是体系。
六、总结
选工具之前，先盘流程。盘完你能看清：时间花哪了、信息漏哪了、哪些活该给 AI、哪些判断得自己扛。
不用把整个研发流程一次性交给 AI，先从一个重复、能给上下文、结果能验的小节点开始。
等 AI 真正嵌进需求澄清、代码理解、方案设计、测试排障和复盘沉淀，它就不再是你偶尔打开的聊天窗口，而是你流程里的一员干将。
到时候你换不换工具都无所谓了------因为你已经知道，问题从来不在工具，在你自己。
（评论区聊聊：你日常最耗时、最想让 AI 帮忙的环节是哪个？顺便说一声，下一篇拆 AI 编程工作台，工具、模型、基础配置一次讲完，记得来。）
P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/H1727548