精准开发协议

要解决什么问题

让 Agent 改代码时，最常见的损失不是「写不出来」，而是改多了、改错了、反复试错烧积分：用户只说动底部栏，却连带改了场地尺寸；Edit 在 GBK 乱码文件上连试十几次；编译命令看似成功却输出到 H5 目录。本协议把这些来自真实项目（如小程序记分牌场景）的教训，收成可执行的纪律。

技能如何工作

核心是 WorkBuddy 式精准交付，而不是「看到能改就顺手改」：

• 编辑边界沙箱：动手前用五问自检——改哪个文件、哪一行、是否在用户范围内、会不会误伤、如何验证；用户说改 A 就只改 A。
• 平台坑点查表：微信小程序/CSS、uni-app 编译、文件编码等问题先查表再动手（如 margin-top 挤压 flex 兄弟、margin-top: auto 无效、@blur 先于 @click、Vue3 用 uni build -p mp-weixin 等）。
• 工具失败止损：同一策略 2 次失败即切换（例如乱码文件 Read + Write 整文件重写，而不是死磕 Edit）。
• 成本与闭环：并行 Read、回复简洁；改完 编译 → 检查输出目录 → Grep 确认；稳定状态再 git commit/打标签。
• 方案确认（布局/顺序类）：DOM 顺序不等于视觉顺序；改 UI 前先描述方案并让用户确认，同一天同一功能连续失败两次应熔断停手。

文档还提供标准执行流程模板与案例库（场地缩小、row-reverse 换场、输入丢失等），对应 30 条铁律 快速对照。

适用边界

• 规则与案例偏重微信小程序 + uni-app 实战；其它栈需自行迁移查表思路，不能照搬每条 CSS 结论。
• 这是改代码的行为协议，不替代产品需求分析或从零架构设计。
• Git、沟通简洁等约定假设你在 Cursor/类 Agent 环境里按 tool call 计费使用。