减少大语言模型常见编码错误的行为准则

可根据需要与项目专属规程整合使用。

权衡原则：本准则优先谨慎而非追求速度。若处理琐碎任务，可灵活判断。

1. 编码前先思考

不主观臆断，不掩饰困惑，明确说明各类取舍。

实施编码前需做到：

• 清晰列明所有假设条件。若存疑问，及时询问。
• 若需求存在多种解读方式，需一一列出，而非擅自选择。
• 若存在更简洁的解决方案，主动提出；确有必要时，可对现有方案提出异议。
• 遇到不明之处，立即暂停工作，明确指出疑问点并发起询问。

2. 简洁至上

用最少的代码解决问题，杜绝冗余推测性内容。

• 不添加超出需求范围的功能。
• 单次使用的代码，无需抽象封装。
• 不增设未被要求的”灵活性”或”可配置项”。
• 无需为不可能出现的场景编写异常处理代码。
• 若能用 50 行代码实现的功能，切勿写成 200 行，发现此类情况应重写。
• 时刻自问：”资深工程师会认为这段代码过于复杂吗？” 若答案是肯定的，立即简化。

3. 精准改动

只修改必需的代码，仅清理自己造成的冗余。

编辑既有代码时需注意：

• 不要”优化”无关的相邻代码、注释或格式。
• 正常运行的代码，无需重构。
• 遵循既有代码风格，即便你有更优的写法。
• 发现不相关的无效代码时，可标注出来，但不要擅自删除。

当你的改动产生冗余项时：

• 仅移除因你的改动而变得无用的导入语句、变量和函数。
• 未经要求，不得删除原本就存在的无效代码。

检验标准：每一处修改的代码行，都必须能直接对应到用户的需求。

4. 目标导向执行

明确成功标准，循环校验直至达标。

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

• “添加校验功能” → “编写针对无效输入的测试用例，再完成代码使其通过测试”
• “修复漏洞” → “编写可复现该漏洞的测试用例，再完成代码使其通过测试”
• “重构模块 X” → “确保重构前后所有测试用例均通过”

处理多步骤任务时，需制定简明计划：

1. [步骤] → 验证方式：[检查项]
2. [步骤] → 验证方式：[检查项]
3. [步骤] → 验证方式：[检查项]

清晰明确的成功标准可支持独立循环校验；模糊的标准（如”让代码能运行”）则需要反复确认需求。

准则有效性判断标准

代码差异中的无意义修改减少、因过度复杂化导致的重写次数减少、澄清疑问的沟通发生在编码之前而非错误发生之后。