本文目录
AI Workflow 不是在开发流程中多加一个聊天窗口，而是把 AI 放进一条有明确输入、输出和验收证据的工作链路。工具可以变化，但任务怎样进入、代码怎样验证、风险怎样控制，应当保持稳定。
一套可靠的 AI 编程工作流需要同时解决三个问题：AI 是否理解了正确目标，改动是否处于可控范围，结果是否有足够证据证明可以交付。
先定义输入、输出和验收#
很多失败并不是模型能力不足，而是任务进入时只有一句模糊需求，结束时也只检查了“看起来能运行”。开始前应明确：
- 输入：业务目标、相关文件、现有行为、限制和风险
- 过程：计划、修改、命令、审批和反馈
- 输出：代码差异、测试结果、文档和剩余风险
- 验收：由谁使用什么证据判断完成
例如“优化搜索功能”无法直接验收；“搜索忽略标题大小写、空关键词不查询数据库，并补充对应测试”才是可执行任务。
第一阶段：整理需求与未知条件#
不要让 AI 在未知条件上连续做决定。先用一个只读回合整理任务：
复述目标和用户场景，列出已确定要求、未知信息、
可能影响现有功能的边界，以及需要查看的文件。
本轮不要修改代码。由开发者确认哪些假设可以接受，哪些需要查看代码、询问产品或读取数据才能判断。高风险任务还要提前标记权限、迁移、兼容性和回滚要求。
第二阶段：准备最小上下文包#
上下文不是越多越好。一次性塞入整个仓库和全部历史讨论，反而会稀释当前任务。有效上下文通常包括：
- 项目入口和依赖文件
- 与需求直接相关的模块
- 相邻功能的现有实现
- 测试、lint 和启动命令
- 仓库级开发约定
- 当前错误、日志或复现步骤
先让 AI 在仓库中定位相关文件，再补充它无法发现的业务背景。长期规则写入项目说明，临时需求仍放在当前任务中。
第三阶段：拆成可验证切片#
一个切片应当可以独立实现、独立验证，并且失败时容易回退。以“给文章列表增加分页”为例，可以拆成：
- 明确页码、每页数量和非法参数行为
- 修改查询并保留原有排序
- 增加上一页、下一页和当前页状态
- 补充空列表、第一页、最后一页和越界测试
- 检查 canonical URL 与移动端布局
每完成一个切片就运行对应验证，避免最后同时面对数据、UI 和 SEO 三类问题。
第四阶段：先计划，再修改#
计划的价值是提前发现范围失控。一个有效计划需要说明文件、数据流、验证方式和潜在风险。
基于已经读取的项目，给出不超过六步的实施计划。
每一步列出预计修改的文件和验证方法。
优先复用现有模式，不引入新依赖，不处理无关重构。
计划确认前不要写文件。如果计划出现大量无关文件、新框架或数据库重建，应先缩小任务。确认后再逐步执行，并报告实际改动与计划偏差。
第五阶段：建立分层验证#
“测试通过”不是单一结论。不同层次验证不同风险：
- 静态检查：语法、格式、类型和依赖配置
- 单元测试：函数、规则和边界输入
- 集成测试：数据库、文件、接口和权限
- 用户流程：从入口到结果的完整操作
- 非功能检查：性能、可访问性、移动端和安全
让 AI 运行项目现有命令，但不要让它为了通过检查而删除断言、跳过测试或改写基线。无法运行的检查必须记录原因。
第六阶段：独立审查差异#
完成后切换到审查视角。可以新开上下文，只提供目标、约束和 Diff，让 AI 优先寻找问题而不是继续实现。
审查重点包括：
- 是否满足原始验收条件
- 是否修改了任务之外的行为
- 输入验证和权限是否只存在于前端
- 错误路径、空状态和并发是否处理
- 是否引入重复代码、隐式依赖或敏感信息
- 测试是否真的覆盖新增逻辑
AI 审查可以扩大覆盖面，但业务正确性和高风险代码仍由人负责确认。
第七阶段：交付与回滚#
进入部署前，应整理一份短记录：
- 本次解决和没有解决的问题
- 数据库或配置是否变化
- 已运行的验证命令及结果
- 部署顺序和依赖条件
- 失败时如何回滚
- 上线后观察哪些指标
数据库变更先验证兼容和备份；界面变更保留关键截图；外部 API 需要考虑超时、限流和降级。
第八阶段：复盘并沉淀资产#
复盘不是保存整段聊天，而是提炼以后仍然有用的信息：容易误判的入口、快速验证命令、需要额外审批的任务和常见失败模式。
稳定规则写入项目文档，重复步骤做成脚本或 CI 检查，领域知识整理成可检索说明。只有能够复用，单次对话才会转化为长期效率。
一个完整任务模板#
目标：说明用户问题和期望结果。
现状：给出当前行为、复现步骤和相关模块。
范围：列出必须修改和禁止修改的部分。
约束：技术栈、兼容性、安全和性能要求。
验收：自动化命令、手动流程和边界场景。
先阅读项目并复述理解，列出未知条件；
再给出文件级计划，确认后分步实施；
每一步运行验证；最后审查 Diff，汇报证据和剩余风险。简单任务可以缩短模板，但目标、范围和验收不应缺失。
怎样衡量工作流是否有效#
不要只统计生成了多少代码。更有意义的指标包括：
- 从任务开始到首次可验证结果的时间
- 一次验收通过率和返工次数
- AI 改动中被人工撤销的比例
- 回归缺陷和生产事故数量
- 测试覆盖的关键路径数量
- 相似任务复用规则或脚本的比例
如果速度提高但返工和缺陷同时增加，工作流只是把问题推迟到了后面。
常见反模式#
一个提示完成整个产品#
任务过大时，AI 会在多个未知条件上连续做决定。应拆成能独立验收的垂直切片。
每次都从零解释项目#
把稳定命令、目录边界和架构约定写入仓库文档，避免上下文重复且不一致。
只接受最终总结#
总结可能遗漏真实差异。始终查看文件变更、命令输出和测试证据。
失败后不断增加提示长度#
先补充复现步骤、错误日志和环境差异。更多文字不等于更有效上下文。
从最小闭环开始#
个人开发者可以先采用最小版本：任务卡写目标和验收，AI 先读再改，完成后运行检查并查看 Diff，最后记录一个可复用结论。
当这条闭环稳定后，再加入独立审查、自动化测试、部署检查和效果度量。AI Workflow 的价值不在流程复杂，而在每一步都减少不确定性，并让交付质量可以被证明。