如果你是独立开发者、一人公司或需要自行维护产品的自由职业者，AI 编程最适合承担的不是“替你做决定”，而是把每个开发阶段的检查工作接起来：先澄清需求，再理解现有代码，接着提出实现方案，最后生成测试和发布前检查清单。这样做的目标不是让 AI 一次写出更多代码，而是减少需求遗漏、重复解释和低级回归。

先确定 AI 在流程中的位置

一套适合个人开发者的 AI 编程流程，可以拆成五个阶段：

1. 需求拆解：把模糊想法变成用户场景、规则和验收条件。
2. 代码理解：让 AI 先阅读项目结构和相关文件，解释现有逻辑与约束。
3. 实现建议：比较几种实现路径，明确改动范围和潜在风险。
4. 测试验证：根据需求和现有测试框架补充测试用例。
5. 发布检查：检查代码变更、配置、兼容性和回滚方式。

AI 在这里更像一个随时可以提问的检查助手。你仍然需要判断业务优先级、接受还是拒绝某个方案，并对最终代码负责。

尤其是涉及支付、权限、客户数据、数据库结构或线上配置时，不要因为 AI 给出了完整代码，就跳过人工审阅和本地验证。

第一步：把需求拆成可检查的条件

不要直接输入“帮我做一个商品搜索功能”。这类描述缺少边界，AI 可能自行决定分页、排序、模糊匹配方式，甚至修改不在本次范围内的代码。

可以先把需求整理成下面的格式：

功能：商品搜索

目标用户：
- 在后台输入关键词，查找商品。

已确认规则：
- 按商品名称进行包含匹配。
- 空关键词返回全部商品。
- 自动去除关键词首尾空格。
- 没有匹配结果时返回空数组。
- 查询必须使用参数化方式。

本次不做：
- 不增加分页。
- 不增加排序。
- 不修改商品数据结构。
- 不增加新的权限角色。

验收条件：
- 输入“咖啡”可以匹配“手冲咖啡”。
- 输入“  咖啡  ”与输入“咖啡”结果一致。
- 输入空字符串时返回全部商品。
- 没有结果时接口返回空数组。
- 异常情况有明确的错误处理。

然后让 AI 只做需求检查，而不是立即写代码：

请检查这份需求：
1. 找出仍然不明确的地方；
2. 列出可能被误解的边界条件；
3. 将需求转换成可执行的验收清单；
4. 不要生成代码，也不要自行增加功能。

如果 AI 提出分页、排序或新的筛选条件，先判断它们是否真的属于当前任务。对一人公司来说，控制变更范围往往比一次性增加功能更重要。

第二步：让 AI 先理解代码，再提出方案

代码解释阶段的关键，不是让 AI 总结整个项目，而是给它一个明确的阅读范围。一次提供太多无关文件，反而容易让结论失焦。

可以按以下顺序提供上下文：

• 项目目录结构；
• 负责路由或入口的文件；
• 相关业务服务；
• 数据访问层或接口定义；
• 现有测试文件；
• 与本次变更有关的配置说明。

提示词可以这样写：

请先阅读以下项目结构和相关文件，不要修改任何代码。

请回答：
1. 当前请求从哪里进入；
2. 经过哪些函数或模块；
3. 数据从哪里读取，最终如何返回；
4. 现有代码有哪些约束；
5. 哪些文件最可能需要修改；
6. 哪些文件不应该修改；
7. 你无法确认的地方分别是什么。

请引用具体的文件路径和函数名，不要根据未提供的文件自行推测。

这一步的产物应该是一份“当前实现说明”，而不是代码。你可以检查 AI 是否准确理解了调用链，再决定是否进入实现阶段。

如果项目已有测试，务必把相关测试文件一起提供。测试文件通常能说明项目使用的断言方式、命名习惯、数据准备方式和边界约定。只看生产代码而不看测试，容易生成风格不一致、无法直接运行的测试。

第三步：先要实现计划，再接受代码修改

在让 AI 编写代码之前，先让它给出一个小范围实现计划：

基于已确认的需求和现有代码，请提供实现计划。

要求：
- 只覆盖本次商品搜索功能；
- 列出需要修改、新增和明确不修改的文件；
- 说明每个文件的改动目的；
- 标出输入校验、数据库查询和错误处理位置；
- 说明可能影响的现有功能；
- 不要输出完整代码。

方案确认后，再要求它按计划实现：

请按照已确认的实现计划修改代码。

约束：
1. 不改变公开接口格式；
2. 不增加分页、排序或额外筛选；
3. 使用项目已有的数据库访问方式；
4. 先展示拟修改的文件和关键差异；
5. 不修改测试以外的无关文件；
6. 如果发现需求或现有代码存在冲突，先停下来说明。

“先展示差异”很重要。你需要看到 AI 准备改哪些文件，而不是等它完成后才从大量变更中寻找问题。

一个适合独立开发者的最小变更记录可以包括：

任务：增加商品名称搜索
日期：2025-XX-XX

需求范围：
- 包含匹配
- 去除首尾空格
- 空关键词返回全部
- 参数化查询

变更文件：
- src/routes/products：接收查询参数
- src/services/product-search：处理搜索规则
- tests/product-search：增加边界测试

明确未修改：
- 商品表结构
- 权限逻辑
- 分页和排序

验证结果：
- 本地单元测试：通过/失败
- 集成测试：通过/失败
- 手工检查：待完成

日期和文件名应以你的实际项目为准。记录的价值不在于格式漂亮，而在于下次排查问题时，能够快速知道为什么改、改了什么、验证到哪一步。

第四步：让测试覆盖规则，而不是只追求数量

测试用例应直接对应需求中的规则。对于商品搜索，可以先列出测试矩阵：

让 AI 生成测试时，应要求它先查看项目已有写法：

请使用项目现有的测试框架和测试风格，为商品搜索补充测试。

要求：
1. 先说明现有测试文件采用的组织方式；
2. 覆盖需求中的每条验收条件；
3. 每个测试包含明确断言；
4. 使用测试夹具或模拟数据，不连接真实生产数据库；
5. 不修改生产代码；
6. 说明每个测试验证了什么；
7. 如果现有代码无法测试某条规则，请指出原因。

测试通过也不代表功能一定正确。至少还要人工检查以下问题：

• 空值、空字符串和只包含空格的输入是否被区分；
• 查询参数是否经过安全处理；
• 返回数据结构是否保持兼容；
• 错误是否被吞掉，导致调用方误以为查询成功；
• 测试是否只验证了“有结果”，却没有验证结果内容；
• 测试数据是否掩盖了重复记录或大小写差异。

AI 可以帮助你补齐候选测试，但不能替你判断这些规则是否符合真实业务。

第五步：把代码审查变成独立的一轮检查

不要让同一次对话既生成代码又宣布代码“没有问题”。更稳妥的做法是，在代码和测试完成后，重新整理上下文，让 AI 以审查者身份检查变更。

请审查下面这次代码修改。

已确认需求：
- 按商品名称包含匹配；
- 空关键词返回全部商品；
- 去除关键词首尾空格；
- 无结果返回空数组；
- 使用参数化查询；
- 本次不增加分页和排序。

请重点检查：
1. 是否遗漏任何需求；
2. 是否引入了超出范围的行为；
3. 是否存在输入校验、权限、数据泄露或查询安全风险；
4. 是否破坏原有接口；
5. 测试是否覆盖关键边界；
6. 是否需要补充回滚或兼容性说明。

请按“问题等级、文件位置、问题说明、建议验证方式”输出。
如果没有发现问题，也请列出已检查的项目，不要只回复“通过”。

可以把代码审查分成两轮：

逻辑审查

关注业务规则、分支条件、异常处理和接口兼容性。例如：

• 空关键词是否真的返回全部；
• 去空格发生在查询前还是查询后；
• 无结果和查询失败是否被错误地当成同一种情况；
• 新逻辑是否影响其他调用方。

工程审查

关注变更范围、测试、配置和发布风险。例如：

• 是否修改了不相关文件；
• 是否新增了未记录的环境变量；
• 是否需要数据库迁移；
• 本地测试命令是否可重复执行；
• 是否存在没有加入版本控制的文件。

如果你使用多个 AI 工具，也可以让一个工具辅助实现，另一个工具只负责检查。但这并不自动等于更可靠，关键仍然是输入明确、角色分离，并由你核对实际代码。

发布前：用清单完成最后一道门

发布前不要只问 AI“可以上线吗”，而要让它根据具体变更生成检查表：

根据本次商品搜索功能的需求、代码差异和测试结果，生成发布前检查清单。

请分为：
- 功能验证
- 回归验证
- 安全与数据
- 配置与部署
- 监控与回滚

每项都要写成可以勾选的动作。
不要假设未提供的验证已经完成。

你可以将最终清单缩减为自己的固定模板：

• [ ] 需求中的每个验收条件都有对应验证；
• [ ] 生产代码和测试代码的变更都已阅读；
• [ ] 本地测试通过，失败项已解释；
• [ ] 关键路径完成手工验证；
• [ ] 没有提交密钥、客户数据或本地临时文件；
• [ ] 数据库、环境变量和部署配置已确认；
• [ ] 已记录本次变更和已知限制；
• [ ] 已准备回滚方式；
• [ ] 发布后知道观察哪些错误或异常。

对于一人公司，这份清单还能成为交付记录。未来客户反馈问题时，你可以回看当时的需求、代码差异和验证结果，而不必重新依靠记忆解释整个过程。

一套可以长期复用的最小闭环

把整个流程压缩成日常操作，就是：

1. 写清楚本次要解决的问题和不做什么；
2. 让 AI 解释相关代码，不急着修改；
3. 确认实现计划和变更范围；
4. 让 AI 按计划生成代码或补充实现；
5. 根据验收条件生成测试；
6. 在本地运行测试并查看真实差异；
7. 让 AI 进行独立代码审查；
8. 人工确认业务决策和风险；
9. 记录变更、验证结果与回滚方式；
10. 发布后观察实际表现。

这套 AI 编程流程的核心不是某个具体工具，也不是让模型承担完整开发职责，而是把需求拆解、代码理解、实现建议、测试流程和代码审查连接起来。AI 可以减少重复解释，帮助你发现遗漏；但范围控制、技术取舍、数据安全和最终发布，仍然需要由独立开发者亲自决定。