2026Technology-Competition/agents.md

使用中文回答问题

日志规则（自动执行）

每次创建或修改代码文件后，在项目根目录的 _AI_USAGE_LOG.md 中追加一条记录，必须包含以下字段：日期时间、范式步骤、修改摘要、涉及文件、使用模型

说明：

• AI自动填充"日期时间""修改摘要""涉及文件"和"使用模型"，若AI无法获取当前使用模型，可以手动加上。
• "范式步骤"列根据实际情况写，比如需求分析、设计方案、实施计划等开发范式。

1. 在编码前三思

别妄下定论。不要掩饰困惑。表面权衡。

在实施之前：

• 明确表达你的假设。如果不确定，可以问。
• 如果存在多种解读，就提出来——不要默默选择。
• 如果有更简单的方法，请说明。必要时反驳。
• 如果有什么不清楚的地方，就停止。说出什么让人困惑。问吧。

2. 简洁优先

只需解决问题的最低限度代码。不要做任何推测性的。

• 除了被要求的部分，没有其他特征。
• 一次性代码不做抽象。
• 没有没有“灵活性”或“可配置性”，这是他们主动要求的。
• 不可能的情景没有错误处理。
• 如果你写了200行，可能只有50行，那就重写。

问问自己：“高级工程师会说这太复杂了吗？”如果是，那就简化。

3. 手术变更

只触碰你必须触碰的部分。只收拾你自己的烂摊子。

编辑现有代码时：

• 不要“改进”相邻的代码、注释或格式。
• 不要重构那些没有坏掉的东西。
• 即使你会用不同的方式，也要匹配现有的风格。
• 如果你发现了无关的死代码，要提一提——不要删除。

当你的更改产生孤儿时：

• 移除那些是你自己改动导致没用到的导入/变量/函数。
• 除非被要求，不要删除已有的死代码。

测试：每一行更改的线条都应直接追踪到用户的请求。

4. 目标驱动执行

定义成功标准。循环直到确认。

将任务转化为可验证的目标：

• “添加验证”→“为无效输入写测试，然后让它们通过”
• “修复bug”→“写一个复现它的测试，然后让它通过”。
• “重构X”→“确保测试在前后通过”

对于多步骤任务，请提出简要计划：

1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]