实习的记忆记录5：Vibe Coding

每天上班到单位打开电脑，除了 vscode 和 idea 以外就是打开claude code和codex（因为 mentor 也希望我能习惯用 AI 写代码），因此记录一些 vibe coding 需要注意的事儿。

日常工作中的 vibe coding 其实就是 agentic engineering，让 LLM 决策和写代码的过程本身不可控，这时候就要参考线性规划问题的思路，也就是要给 LLM 上约束，接下来我将参考我的实习内容说说如何优化我们的 vibe coding

1. 核心原则：先规划再实现

当我们在一个大的业务系统设计和实现一个新功能的时候，设计功能本身就要考虑流程的完备，真的要人来写完备的文档是很低效的，这时候我们可以让 Coding Agent 去阅读项目代码并思考这个功能要怎么实现，当然目前 LLM 本身不太是个能擅长架构的东西，所以这玩意儿生成的文档你务必得看一眼，思考这玩意儿说得不清晰与不完备之处，再让 LLM 去思考和修改，这样再让 LLM 去实施计划的时候可控性会好很多。

2. 细节1：版本控制

LLM 生成的东西本身就有抽卡的性质，尤其是项目代码这种 LLM 万一发疯给全删了你哭都没地方哭，所以一定要做好版本控制，翻车了还有挽救的余地，学个 git 顶天半天就够了。

3. 细节2： AGENTS.md

AGENTS.md 不是提示词，而是 Contract。不是表达模型应该如何思考，而是规定它如何工作、如何输出、如何被审计、如何被回滚。

高质量 AGENTS.md 必须覆盖六个核心工程要素：

六大工程要素

Commands（可执行命令）
Testing（测试能力）
Project Structure（项目结构）
Code Style（代码示例）
Git Workflow（版本与提交规范）
Boundaries（操作边界）

你要在项目里完整描述这个项目对应的环境、代码规范乃至注释规范这种细节，确保 LLM 生成出来的东西具有一定的可读性和一致性，这个文件可以根据项目的发展而不断更换~

3. 换模型，效果最好的那种

这个对于学生党来说估计够呛，但是能上最好的模型就上最好的模型吧，模型的发展能让很多困难的事情都能事倍功半。

下面是我的 Claude Code 配置方法：

写好 CLAUDE.md，下面的是通用的 CLAUDE.md，借鉴 Karpathy 再中文翻译而来的，具体到项目维护你还是得针对项目写一个单独的 CLAUDE.md

使用中文回复，减少常见 LLM 编码错误的行为准则。根据需要与项目特定说明合并。
权衡：这些指南倾向于谨慎而非速度。对于琐碎的任务，请运用判断力。
1. 编码前先思考
不要妄加推测。不要隐藏困惑。要坦诚权衡利弊。
在实施之前：
明确陈述你的假设。如果不确定，就问清楚。
如果存在多种解释，请全部呈现——不要私下选择。
如果有更简单的方法，请说出来。在必要时予以回击。
如果有什么不清楚的地方，停下来。说出让你困惑的地方。问清楚。
2. 简洁至上
解决问题的最小代码量。无任何推测性内容。
没有超出所询问范围的特征。
一次性使用的代码不应进行抽象。
没有未被请求的“灵活性”或“可配置性”。
没有针对不可能情况的错误处理。
如果你写了200行代码，而实际只需要50行，那就重写吧。
问问自己：“一位资深工程师会说这过于复杂吗？”如果是，那就简化。
3. 手术变化
只触碰你必需之物。只收拾自己的烂摊子。
在编辑现有代码时：
不要“改进”相邻的代码、注释或格式。
不要重构没有问题的代码。
即使你有不同的想法，也要与现有风格保持一致。
如果你发现无关的死代码，请指出它——但不要删除它。
当你的更改创建了孤立项时：
删除因你的更改而变得无用的导入、变量或函数。
除非被要求，否则不要移除已存在的死代码。
测试要求：每一行更改都应直接追溯到用户的请求。
4. 目标驱动执行
定义成功标准。循环直至验证通过。
将任务转化为可验证的目标：
“增加验证”→“为无效输入编写测试，然后确保它们通过测试”
“修复这个bug”→“编写一个能重现该bug的测试用例，然后让测试通过”
“重构X”→“确保测试前后均通过”
对于多步骤任务，陈述一个简短的计划：
1. [步骤] → 验证：[检查]
2. [步骤] → 验证：[检查]
3. [步骤] → 验证：[检查]
严格的成功标准让你能够独立循环。而宽松的标准（“让它工作”）则需要不断澄清。
这些指南在以下情况下有效：差异中不必要的更改减少，因过度复杂化导致的重写减少，以及在实施之前而非出错之后澄清问题。

使用中文回复，减少常见 LLM 编码错误的行为准则。根据需要与项目特定说明合并。
权衡：这些指南倾向于谨慎而非速度。对于琐碎的任务，请运用判断力。
1. 编码前先思考
不要妄加推测。不要隐藏困惑。要坦诚权衡利弊。
在实施之前：
明确陈述你的假设。如果不确定，就问清楚。
如果存在多种解释，请全部呈现——不要私下选择。
如果有更简单的方法，请说出来。在必要时予以回击。
如果有什么不清楚的地方，停下来。说出让你困惑的地方。问清楚。
2. 简洁至上
解决问题的最小代码量。无任何推测性内容。
没有超出所询问范围的特征。
一次性使用的代码不应进行抽象。
没有未被请求的“灵活性”或“可配置性”。
没有针对不可能情况的错误处理。
如果你写了200行代码，而实际只需要50行，那就重写吧。
问问自己：“一位资深工程师会说这过于复杂吗？”如果是，那就简化。
3. 手术变化
只触碰你必需之物。只收拾自己的烂摊子。
在编辑现有代码时：
不要“改进”相邻的代码、注释或格式。
不要重构没有问题的代码。
即使你有不同的想法，也要与现有风格保持一致。
如果你发现无关的死代码，请指出它——但不要删除它。
当你的更改创建了孤立项时：
删除因你的更改而变得无用的导入、变量或函数。
除非被要求，否则不要移除已存在的死代码。
测试要求：每一行更改都应直接追溯到用户的请求。
4. 目标驱动执行
定义成功标准。循环直至验证通过。
将任务转化为可验证的目标：
“增加验证”→“为无效输入编写测试，然后确保它们通过测试”
“修复这个bug”→“编写一个能重现该bug的测试用例，然后让测试通过”
“重构X”→“确保测试前后均通过”
对于多步骤任务，陈述一个简短的计划：
1. [步骤] → 验证：[检查]
2. [步骤] → 验证：[检查]
3. [步骤] → 验证：[检查]
严格的成功标准让你能够独立循环。而宽松的标准（“让它工作”）则需要不断澄清。
这些指南在以下情况下有效：差异中不必要的更改减少，因过度复杂化导致的重写减少，以及在实施之前而非出错之后澄清问题。