我是如何利用 AI 来交付代码的
不要再试图编写精妙的提示词了。开始进行上下文工程（context engineering）吧。
大多数人使用 AI 的方式都是错误的。他们用一句话要求实现一个功能。AI 返回的代码可能会使用错误的库、破坏你的命名规范，并重新引入旧的 Bug。你不得不花整个下午来收拾烂摊子。
没有上下文的 AI 就像一个从未读过你代码库的初级开发人员。它会忘记昨天发生的一切。你不会只给一个新员工发一个只有一行的任务单，就指望他写出完美的代码。你会给他们一份入职文档。
我在仓库中使用一个“项目记忆文件”（project memory file）。这个文件充当 AI 每次都会阅读的入职文档。它包含了外部人员无法了解的项目特定规则：
• 必须遵守的规范：URL 的格式要求以及 slug 如何与生产环境保持一致。 • 逻辑规则：从配置中获取值，而不是硬编码数字。 • 边缘情况：防止静默失效的特定 CDN 设置或文件路径。
我犯的每一个错误都会变成该文件中的一行。这使得该文件变成了一种具有复利效应的资产。随着时间的推移，AI 输出的质量会不断提高，因为我不再需要重复同样的要求。
我的工作流遵循以下步骤：
- 初始化上下文：让 AI 根据你的代码起草记忆文件，然后由你进行编辑。
- 重述任务：在 AI 编写代码之前，让它先总结目标。这可以及早发现错误。
- 优化提示词：询问 AI 你的请求中哪些地方存在歧义。
将 AI 用于这些任务：
- 编写样板代码（boilerplate）和脚手架（scaffolding）。
- 遵循既定模式的重构。
- 解释陌生的代码。
- 对整个仓库进行机械性的扫描。
- 编写测试和测试固件（fixtures）。
避免将 AI 用于这些任务：
- 做出创新的架构决策。
- 做出审美或产品层面的决策。
- 任何出错代价高昂的任务。
- 安全关键型设计。
- 发布前的最终审查。
这种纪律很简单：
- 缩小任务范围。不要说“构建这个功能”，而要说“执行这项特定的更改”。
- 预先提供上下文。
- 验证每一项输出。运行构建并查看 diff。
- 像审查初级开发人员的 PR 一样进行审查。在没有人工阅读的情况下，绝不要提交代码。
- 将经验教训反馈到你的上下文文件中。
杠杆不在于提示词，而在于你维护的上下文。
Optional learning community: https://t.me/GyaanSetuAi