1. 编码前思考
不要假设。不要隐藏困惑。呈现权衡。
LLM 经常默默选择一种解释然后执行。这个原则强制明确推理：
明确说明假设 — 如果不确定，询问而不是猜测
呈现多种解释 — 当存在歧义时，不要默默选择
适时提出异议 — 如果存在更简单的方法，说出来
困惑时停下来 — 指出不清楚的地方并要求澄清
2. 简洁优先
用最少的代码解决问题。不要过度推测。

对抗过度工程的倾向：
不要添加要求之外的功能
不要为一次性代码创建抽象
不要添加未要求的"灵活性"或"可配置性"
不要为不可能发生的场景做错误处理
如果 200 行代码可以写成 50 行，重写它
检验标准： 资深工程师会觉得这过于复杂吗？如果是，简化。

3. 精准修改
只碰必须碰的。只清理自己造成的混乱。
编辑现有代码时：
不要"改进"相邻的代码、注释或格式
不要重构没坏的东西
匹配现有风格，即使你更倾向于不同的写法
如果注意到无关的死代码，提一下 —— 不要删除它
当你的改动产生孤儿代码时：
删除因你的改动而变得无用的导入/变量/函数
不要删除预先存在的死代码，除非被要求
检验标准： 每一行修改都应该能直接追溯到用户的请求。

4. 目标驱动执行
定义成功标准。循环验证直到达成。
将指令式任务转化为可验证的目标：
不要这样做...	转化为...
"添加验证"	"为无效输入编写测试，然后让它们通过"
"修复 bug"	"编写重现 bug 的测试，然后让它通过"
"重构 X"	"确保重构前后测试都能通过"
对于多步骤任务，说明一个简短的计划：
1. [步骤] → 验证: [检查]
2. [步骤] → 验证: [检查]
3. [步骤] → 验证: [检查]
强有力的成功标准让 LLM 能够独立循环执行。弱标准（"让它工作"）需要不断澄清。
C++代码使用gb2312编写代码,不能使用任何转义.lua类型代码使用utf-8编码编写,风格格式化该换行的地方一定要换行.
改写功能尽量使用原始底层代码API,尽量不要使用锁.尽量不要过于改写底层代码.尽量不要做多余的内容修改.
编辑好代码后不要直接编译成exe,由人工审查自行编译.
C++编写的后端功能尽量使用单类创建.不允许使用namespace,不允许使用魔数,数字类型应使用宏或者枚举