69 lines
2.7 KiB
Markdown
69 lines
2.7 KiB
Markdown
---
|
||
title: AI Agent 开发最佳实践
|
||
slug: ai-agent-best-practices
|
||
status: inbox
|
||
content_type: reference
|
||
source: transcript
|
||
created_at: 2026-03-03T19:57:50+08:00
|
||
updated_at: 2026-03-03T20:30:00+08:00
|
||
tags: [ai, agent, best-practices, development]
|
||
---
|
||
|
||
# 工作流编排
|
||
|
||
### 1. Plan Node Default（计划节点默认规则）
|
||
- 对任何非平凡任务（3步以上或架构决策）进入计划模式
|
||
- 如果出现问题，立即停止并重新计划，不要继续推进
|
||
- 将计划模式用于验证步骤，而不仅仅是构建步骤
|
||
- 事先编写详细的规范以减少歧义
|
||
|
||
|
||
### 2. Subagent Strategy（子代理策略）
|
||
- 自由使用子代理以保持主上下文窗口清晰
|
||
- 将研究、探索和并行分析卸载到子代理
|
||
- 对于复杂问题，通过子代理投入更多计算资源
|
||
- 每个子代理专注执行一个任务以实现专注执行
|
||
|
||
|
||
### 3. Self - Improvement Loop（自我改进循环）
|
||
- 在用户进行任何修正后：按照模式更新 `tasks/lessons.md`
|
||
- 为自己编写防止犯同样错误的规则
|
||
- 严格迭代这些经验教训直到错误率下降
|
||
- 在会话开始时回顾相关项目的经验教训
|
||
|
||
|
||
### 4. Verification Before Done（完成前验证）
|
||
- 在未证明其有效前，不要将任务标记为完成
|
||
- 当相关时，比较主流程与你的更改的行为差异
|
||
- 自问："资深工程师会批准这个吗？"
|
||
- 运行测试、检查日志、证明正确性
|
||
|
||
|
||
### 5. Demand Elegance (Balanced)（追求优雅（平衡））
|
||
- 对于非平凡的更改：暂停并自问"是否有更优雅的方式？"
|
||
- 如果一个修复感觉是临时的： "基于我现在知道的一切，实现优雅的解决方案"
|
||
- 对于简单、明显的修复则跳过此步骤——不要过度工程化
|
||
- 在展示工作前挑战自己的工作
|
||
|
||
|
||
### 6. Autonomous Bug Fixing（自动错误修复）
|
||
- 当收到错误报告时：直接修复它。不要寻求手把手指导
|
||
- 指出日志、错误、失败的测试——然后解决它们
|
||
- 不需要用户切换上下文
|
||
- 在未被告知如何操作的情况下修复失败的CI测试
|
||
|
||
|
||
## 任务管理
|
||
1. **先计划**：编写计划到 `tasks/todo.md`，包含可检查的项
|
||
2. **验证计划**：在开始实施前确认计划
|
||
3. **跟踪进度**：在推进过程中标记项为完成
|
||
4. **解释变更**：每个步骤的高层摘要
|
||
5. **记录结果**：在 `tasks/todo.md` 中添加审查部分
|
||
6. **捕捉经验**：在修正后更新 `tasks/lessons.md`
|
||
|
||
|
||
## 核心原则
|
||
- **简单优先**：让每次更改尽可能简单。影响最少的代码。
|
||
- **不偷懒**：找到根本原因。没有临时修复。符合资深开发者标准。
|
||
- **最小化影响**：更改应仅触及必要的内容。避免引入错误。
|