为了保持对项目最低程度的控制，我们的底线到底在哪里？我已经放弃了看懂AI生成的所有项目代码，但配合其它策略，这并没有严重伤害我对项目的认识，我相信我做了某些正确的事，使我还没有碰到真正的底线。
本文意在记录我现在使用AI coding 做个人项目的一些心得和规范，方便我未来审视和调整。
不再尝试看懂代码
在做上一个项目时，我对AI的依赖程度到了难以控制的危险范围，所以在这次一开始，我尝试在AI完成每部分功能后，都使用文档记录这个功能的代码内容。
但是不review的收益是显而易见的，让ai总结而不是自己总结，能同样获得一份文档，同时省去大量时间。
最终我不再花时间看懂代码，是因为两个令我信服的观点：
- 大模型的代码水平会超过五年工作经验以内的人
- 观察模型解决问题的思路，比观察代码更有效
第一点让我相信AI的代码质量，在控制一次生成代码量和项目结构的前提下。第二点驱动了我探索AI coding 工作流
使用cursor的工作流
cursor 的 Plan 模式让用户顺理成章地使用AI生成一整块业务逻辑，一整个功能。如果只依赖这个模式，可以在几次对话之内生成上万行 typescript 和 React 代码，但你再也没机会控制项目了。
我现在使用这样的交互方式，结合有可复用性的提示词做这两种工作。
新增功能：
- Ask 模式讨论功能的可行性
- Plan 模式生成详细的，有todo-list和检查点的计划，经过人工review
- 执行计划
测试发现bug：
- Ask 模式寻找bug源头（可以人工提出假设）
- Agent 模式改正
在这两种最常见的情景中，我仅仅增加了第一步的 Ask 以暴露AI的思考内容，因为无论是 Plan 还是 Agent，模型都在生成而不是对话，让它直接针对我的思考给出它的思考，证明它理解我的想法，比研究它生成过程中的思考要好。
我们都已经见过AI改一个问题半天改不过来，回头一看原本的代码面目全非的情况。所以直观地说，我不敢让AI直接上手改bug，还是让它先证明自己找到原因更让人放心。
我们能做的事
有基础的软件工程师相比零基础的爱好者，在用AI写代码时会有些不同吧？尽管因为AI coding 这件事，两者之间的差距在被弥合，但项目规模越大，差距就会越明显。
简单的例子是重构代码，一个项目文件可能本来对应一个功能，当在这之上追加一些功能后，我们就想起来要拆分出一个模块了。不知道这一点的人会更有可能陷入麻烦。
其它的例子包括引导模型用设计模式，控制状态之间的耦合程度以方便AI理解状态机，还有很多在提示词的细枝末节，用得上知识储备的地方。
做出一个产品的门槛正在变低，但它不会轻易降到零，对于我来说这是好事。
