重要 优先使用中文回复和响应，以及写文档。
权衡： 这些指南倾向于谨慎而非速度。对于琐碎任务，使用判断。
不要假设。不要隐藏困惑。暴露权衡。
实施前：
- 明确陈述你的假设。如有不确定，请提问。
- 如果存在多种解释，请呈现它们——不要沉默不语。
- 如果存在更简单的方法，请说明。在适当的时候提出反对意见。
- 如果某事不清楚，请停止。指出令人困惑的地方。提问。
解决问题的最小代码量。不要做没有根据的猜测。
- 不要超出所要求的功能范围。
- 不要为一次性使用的代码添加抽象。
- 不要添加未请求的"灵活性"或"可配置性"。
- 不要为不可能发生的场景添加错误处理。
- 如果你写了200行代码，但实际只需要50行，那就重写它。
问问自己："一个高级工程师会认为这太复杂了吗？" 如果会，那就简化。
只修改必须修改的部分。只清理你自己的烂摊子。
在编辑现有代码时：
- 不要"改进"相邻的代码、注释或格式。
- 不要重构那些没有问题的东西。
- 保持现有的风格，即使你会有不同的做法。
- 如果你发现无关的废弃代码，请指出来——不要删除它。
当你的修改产生孤儿代码时：
- 删除你修改所导致未使用的导入/变量/函数。
- 除非被要求，否则不要删除现有的废弃代码。
测试：每行修改都应该直接追溯到用户请求。
定义成功标准。循环直到验证通过。
将任务转化为可验证的目标：
- "添加验证" → "为无效输入编写测试，然后使其通过"
- "修复错误" → "编写一个可复现该错误的测试，然后使其通过"
- "重构 X" → "确保在重构前后测试都能通过"
对于多步骤任务，陈述一个简要计划：
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
强大的成功标准让你能够独立循环。薄弱的标准（"让它工作"）需要不断的澄清。
- 项目依赖 Go 1.25+ 和 Bun 1.0+。
- 不要 使用 npm 安装前端依赖。
- 关键方法和逻辑点，需要加上注释说明
- 如果当前任务有进度跟进文件 or 计划文件，需要在完成后更新 checkbox 为已完成
- 多阶段任务，需要在每个子阶段完成后更新进度并提交 Git 提交，不要累计很多文件变动。
- 启动服务时，先 go build 再启动build后的程序，避免直接 go run 需要每次授权卡住
- 使用
github.com/gookit/goutil/x/assert断言结果 - 同一个方法的多个用例使用
t.Run()包裹
require 断言结果的写法：
Require(t, assert.Eq(t, 1, res.ID))
// Standard assertion
assert.Eq(t, expected, actual)