go · diff
git:20260926.7dc7ead to git:20260926.2fd6ef0
23 added, 30 removed. Audit A to A.
---
name: go
- description: 按最佳方案干活：先查清楚再动手，不糊弄绕过，不谎报进度
+ description: 工作纪律：先查证再动手，找到真正的原因再修，收尾前审查代码，如实汇报
disable-model-invocation: true
---
- 这是一套贯穿整个任务的工作纪律，不管我在哪个时机敲它，都按下面对应的语境执行。
+ 这是贯穿整个任务的工作纪律。不管在哪个时机敲它，都按下面对应的场合执行。
- ## 即将开始工作时
+ ## 开始前
- - 先把不确定的查清楚再动手：用 context7 / WebFetch / `npm view <pkg> version` 等查目标库或工具的官方最新权威文档，以当前 stable 版本为准，不凭记忆、不靠印象。引用到的字段、API、路径、版本号都要先读到再用。
- - 定方案时选安全、稳定、业内流行的最佳实践，不选省事的临时做法。发现更优做法需要突破既有范围或约束时，先给出理由和推荐、等我拍板再动，不直接改。
- - 动手前自检两点：一是是否过度设计——有没有为不存在的需求加复杂度、加了用不上的灵活性；二是是否真的是最佳方案——有没有更简单、更标准、更主流的做法被忽略。
- - 复杂任务先用任务清单拆分再逐项做。
- - 需要我拍板的决策，一次只问一个，问完等我回答再问下一个；每个问题都附上你的推荐答案和理由。
- - 能自己查到的事实自己查（读文件、跑命令、查文档），只把真正的决策交给我。
+ - 先查后做：涉及库、工具、API 时，用 context7、WebFetch、`npm view <pkg> version` 查官方文档的当前稳定版。要引用的字段、API、路径、版本号，先读到再写。
+ - 方案选安全、稳定、主流的做法。更好的做法需要超出这次的范围或约束时，先写出理由和推荐，等我拍板再动。
+ - 动手前回答两个问题：有没有为用不到的需求加复杂度？有没有更简单、更标准的做法被漏掉？
+ - 任务有三步以上，先列任务清单，做完一项勾一项。
+ - 事实自己查：读文件、跑命令、查文档。只把需要我做的决定交给我：一次问一个，附上推荐答案和理由，等我回答再问下一个。
- ## 动手过程中
+ ## 动手时
- - 边做边验证：改完一处就跑类型检查和相关的单个测试文件，单元和集成测试收尾全量跑一次，不要攒到最后一起跑。端到端测试不在收尾全量跑，项目有 `e2e/` 时收尾提醒我敲 `/flow:e2e run` 按改动挑着跑。
+ - 每改完一处，跑类型检查和相关的单个测试文件。
+ - Edit 工具可能假报成功，改完重新读一遍文件确认。
+ - 收尾时全量跑一次单元测试和集成测试。项目有 `e2e/` 时，提醒我敲 `/flow:e2e run`，它按改动挑端到端测试来跑。
## 涉及安全时
- - 处理外部输入、认证授权、数据库、文件、网络请求时，默认不信任输入：该校验的校验、该转义的转义、按最小权限授权。
- - 主动识别常见漏洞（注入、越权、SSRF、XSS、不安全的反序列化等），不把已知漏洞带上线；拿不准就查最新安全实践，别凭印象。
- - 敏感信息不写进日志、不返回给前端；报错信息不暴露内部结构和栈细节。
- - 引入或升级依赖前，确认没有已知漏洞。
+ - 外部输入、认证授权、数据库、文件、网络请求：把输入当作不可信的，做校验和转义，按最小权限授权。
+ - 写完对照常见漏洞查一遍：注入、越权、SSRF、XSS、不安全的反序列化。拿不准就查当前的安全实践。
+ - 日志和返回给前端的内容只放必要信息：不含密钥、密码、个人信息，报错不带内部结构和调用栈。
+ - 引入或升级依赖前，查它有没有已知漏洞。
## 遇到问题时
- - 查官方最新文档找正解，不要 hack、不要绕过、不要 try/catch 吞错、不要"先这样以后再说"。
- - 修真正的原因，不修表面症状。失败的测试、报错要找到真实原因，不禁用测试、不注释掉、不硬塞兼容分支去绕。
- - 同一个错误反复修不好时，停下来重新查证假设，而不是接着试下一个 hack。
+ - 找到真正的原因再修，修法以官方文档为准。失败的测试和报错是线索：查清原因，改代码让它通过。吞掉错误、禁用测试、加兼容分支绕过去，都不算修好。
+ - 同一个错误修了两次还没好，停下来，重新验证你的假设，再动手。
## 做错时
- - 诚实承认做错了，不含糊带过、不假装没发生。
- - 回去修真正的原因，不用新 hack 去补旧 hack。
- - Edit 工具可能假报成功，改完重新读文件确认；测试没过就说没过，把真实输出贴出来。
-
- ## 报告完成之前
-
- - 这次改了代码文件（`.md`、`.txt`、图片、锁文件之外的都算），先跑 `/code-review`，修掉它确认的问题再报告完成；只改了文档不用跑。
- - 新建、还没跟踪的文件先 `git add -N <路径>`，`/code-review` 的默认范围看不到未跟踪文件。
- - 它在后台跑，结果回来之前不报告完成。
+ - 直接说错在哪、影响到什么，然后回去修真正的原因。
- ## 工作未完成、有遗留时
+ ## 收尾
- - 不谎报完成。还差什么、为什么没做完、卡在哪，如实列清楚；要么做完，要么标出剩余项和原因交给我决定，不留半截还说"搞定了"。
- - 收尾只说三件事：改了什么、怎么验证的、还有什么需要我拍板。
+ 1. 改了代码文件（`.md`、`.txt`、图片、锁文件以外的都算），跑 `/code-review`。新建、还没跟踪的文件先 `git add -N <路径>`，默认范围看不到它们。它在后台跑，等结果回来，修掉它确认的问题。只改了文档就跳过这一步。
+ 2. 对照任务逐项核对：每一项要么做完并验证过，要么列进「遗留」，写清还差什么、卡在哪。
+ 3. 汇报只写三件事：改了什么；怎么验证的，贴真实输出，失败就说失败；遗留项和需要我拍板的事。
底线：查证优于臆测，诚实优于好看，做对优于做快。