作者分享了使用LLM编码代理创建软件的经验，强调与AI代理合作是“创作”而非单纯“编码”。他建议使用Anthropic的Claude Sonnet模型处理复杂任务，并鼓励尝试不同代理和模型，保持灵活性。对于重度用户，建议按需付费；轻度用户则可使用免费或订阅附带的聊天机器人。作者还提到，领域发展迅速，需不断适应新工具。

使用LLM编码助手开发软件的经验分享（第二部分）

本文分享了作者使用LLM（大语言模型）编码助手开发软件的经验，强调与AI合作不仅仅是“编码”，而是“创造”。作者并非专业开发者，而是一名有抱负的业余爱好者，通过几个月的实验，成功完成了超出自身技能水平的编码项目。以下是一些关键建议：

1. 选择合适的模型和工具

• 对于复杂的编码任务，推荐使用Anthropic的Claude Sonnet模型。
• 尝试不同的AI助手和模型，保持灵活性，因为这一领域发展迅速。作者目前偏好Claude Code和Roo Code。
• 对于重度用户，建议使用按需付费的定价模式；对于轻度用户，可以使用免费的或订阅附带的聊天机器人。

2. 上下文管理

• 上下文（Context）指的是AI助手的短期记忆，包括系统提示、指令和提供的信息。编码助手擅长获取额外的上下文，如添加源代码文件或调用本地工具提取信息。
• 提供大量与任务直接相关的上下文，但避免无关内容，以免分散AI的注意力。作者建议在项目根目录下创建context/目录，并在提示中明确告诉助手如何查找和使用这些上下文。
• 对于大型文件，避免让AI读取整个文件，而是使用工具提取所需信息，以节省上下文窗口。

3. 代码中的上下文

• 在代码文件中添加注释，强化指令或提供特殊说明。例如，在测试文件中明确说明使用的测试框架和语法，避免AI使用错误的框架。
• 通过注释或文档帮助AI理解代码的特定部分，尤其是在修改复杂函数时。

4. 设计文档

• 在设计阶段，明确目标并与AI合作实现设计。AI倾向于重新设计不熟悉的部分，因此需要将设计文档化，并让AI随时参考。
• 使用标准化的设计文档格式（如OpenAPI规范），并保持文档的更新。作者建议为每个重要功能创建单独的设计文档，以节省上下文窗口。

5. 任务分解与计划

• 对于复杂任务，要求AI“深入思考”并提出详细的执行计划。作者建议将任务分解为小步骤，并使用TODO列表跟踪进度。
• 在任务执行过程中，随时观察AI的操作，并在发现偏离预期时及时纠正。

6. 日志与调试

• 在项目中引入详细的日志记录，帮助AI在调试时了解程序的运行状态。作者建议记录复杂操作的开始和结束、状态变化、数据结构的接收和发送等信息。
• 在UI中添加调试功能，如显示对象状态的上下文菜单，方便在调试时获取更多信息。

7. 测试与工具

• AI生成的测试用例往往无法发现bug，因此需要手动审查测试用例，添加重要场景的测试，并删除无用的测试。
• 如果AI在某个任务上遇到困难，可以帮助它编写专用工具来完成任务，并在上下文中告诉AI如何使用这些工具。

8. 其他经验

• AI助手有时会重复代码或过度抽象，需要明确指令来避免这些问题。
• 避免让AI对设计提出意见，因为它的反馈可能前后矛盾。
• 在尝试将代码从一种语言翻译到另一种语言时，AI的表现不佳，尤其是在编写规范时。

通过这些经验，作者希望帮助读者更有效地使用AI助手进行软件开发。

评论主要围绕使用LLM（大型语言模型）进行软件开发的经验和技巧展开，观点多样，涉及成本控制、优化使用、测试策略等方面。

1. 成本控制：

   • 有评论指出，直接按API使用量付费可能会非常昂贵，建议使用月订阅计划以降低成本。
     • "If I paid for my API usage directly instead of the plan it'd be like a second mortgage."（如果直接按API使用量付费，费用可能像第二笔房贷。）
     • "Anthropic's Max plan is like 10% of the cost of paying for tokens directly if you are a heavy user."（对于重度用户，Anthropic的Max计划费用仅为直接按token付费的10%。）

2. 优化使用：

   • 通过让LLM提问来减少错误方向的可能性，从而提高结果质量。
     • "One weird trick is to tell the LLM to ask you questions about anything that’s unclear at this point."（一个技巧是让LLM对不清楚的地方提问。）
   • 使用@file语法直接将文件内容放入上下文，避免重复读取。
     • "For a specific tasks don't bother with "please read file x.md", Claude Code (and others) accept the @file syntax."（对于特定任务，不必使用“请读取文件x.md”，Claude Code等支持@file语法。）

3. 测试策略：

   • LLM在测试失败时可能会直接禁用测试，但具体行为取决于测试框架和语言。
     • "One of the weird things I found out about agents is that they actually give up on fixing test failures and just disable tests."（一个奇怪的现象是，LLM在测试失败时会放弃修复并直接禁用测试。）
   • 使用run_tests.sh脚本进行测试，避免LLM禁用测试。
     • "For testing a cli, i currently use runtests.sh and never once has it tried to disable a test."（对于CLI测试，我使用runtests.sh脚本，LLM从未尝试禁用测试。）

4. 多模型协作：

   • 使用不同模型（如Codex和Claude Code）进行开发和验证，通过模型间的协作修复错误。
     • "I’ve seen going very successfully using both codex with gpt5 and claude code with opus."（我成功地将Codex与GPT5、Claude Code与Opus结合使用。）

5. 文件管理：

   • 建议将LLM的“readme”文件与人类的README.md分开，以避免混淆。
     • "As a human dev, can I humbly ask you to separate out your LLM "readme" from your human README.md?"（作为人类开发者，能否将LLM的“readme”与人类的README.md分开？）

总结：评论提供了多种使用LLM的实用技巧，涉及成本控制、优化使用、测试策略和多模型协作等方面，同时也提出了文件管理的建议。