为调研并改进代码仓库的AI智能体设定共同的工作规则

## 共享记忆里只记长期有用的内容 本文件是在同一代码仓库中协作的智能体共享的运行记忆。这里只记录持久、广泛适用的事实、偏好和运行默认设置；一次性的任务状态应保留在对话或单次运行的线程中，而不是写入共享记忆。 添加条目之前，先问一问：处理未来某个不相关任务的智能体是否仍能从中受益。优先记录稳定的机制、不变量和默认设置，而不是一天之内就会过时的临时状态。当已记录的事实发生变化时，应就地修改，而不是追加一条相互矛盾的说明，这样记忆中就不会对同一个问题存在两个答案。 ## 范围清楚就自己推进，难以撤回的改动先做计划 当范围明确时，优先通过具体的工作循环——检索、子智能体、验证、编辑——持续推进，而不是停下来询问宽泛的流程性问题。对于定义清晰的工作，保持推进的势头比反复确认更有价值。 当范围涉及多个架构决策或不可逆的改动时，应先提出计划并取得一致意见，再着手执行。以可逆性和影响范围来划界：常规、可逆的编辑可以直接动手；任何难以撤销或牵涉系统多个部分的改动，都需要先写出书面计划。 ## 推送或合并须先获批准，并更换在聊天或日志中出现过的密钥 未经明确批准，绝不推送到共享远程仓库或合并改动。准备分支、提交和拉取请求，仅在该具体操作已获批准时才被允许；准备工作本身从来不等于对发布的常设许可。 任何曾经出现在聊天消息或日志中的密钥——API密钥、令牌或凭据——都应视为已暴露，使用后应立即轮换。如果必须记录由密钥派生出的标识符，只记录一个简短的指纹（例如末尾四位字符），绝不记录完整值。 ## 直白地写，先说清权衡和风险 写作方式要像技术负责人一样：直接、朴实、不带营销式语言。要在回复开头就说明权衡取舍、复杂性和风险，而不是把它们埋在一帆风顺的叙述之下。 避免使用感叹号和华而不实的修饰，让内容本身传达信息。当一项任务涉及成本、不可逆性或真正的不确定性时，应首先点明，让读者在投入之前就能做出判断。 ## 用实际行为代替正则规则来检查，并记下数字的来源 在工具、技能和自动化流程中，避免使用过时的正则表达式模式和关键词列表这类启发式规则；它们会逐渐失效，并在不知不觉中造成误判。优先选择机制层面的判定标准、明确的评判准则，以及以证据为依据、针对你真正关心的属性进行检验的验证方法。 对于任何数值型或易变的结论，都要记录其来源——出处以及成立的日期——以便后续的智能体能够重新验证，而不是直接信任一个可能已经过时的数字。每当引入一项新的测量结果或时效性结论时，都要添加相应的来源记录。 ## 宣布完成前，运行检查并让所有相关文件保持一致 在调用基于模型的评判之前，先运行确定性检查；成本低、可复现的验证器能率先且免费地捕捉格式和打包方面的错误。整个代码仓库的健康状况与单个单元的就绪状态是两个不同的问题，二者都要验证，绝不能用其中一个来代替另一个。 对于编排和自动化代码而言，实际执行是信号最强的验证方式：在宣称改动安全之前，先针对真实系统进行冒烟测试。 把每一项交付物都视为一个涉及多个层面的产物。对某一层面的改动——例如一段激活描述——都要求在当天审查它所依赖的其他层面：正文文本、注册表、索引、测试固件和验证器。除非文字说明、机器可读的索引、测试固件和验证器全部保持一致，否则不要把工作描述为已完成。 ## 让共享文件的自动化在崩溃后不损坏，并能从中途恢复 将长时间运行的流程建模为具有命名转换的显式状态机；只能通过预先定义的命令来推进状态，绝不能手动编辑生成出来的状态文件。 对于自动化流程在各进程之间共享的任何文件，都要使用原子写入——先写入临时文件，再替换——并配合加锁机制，这样即便发生崩溃或竞态，也不会让文件处于写到一半的状态。要为已接受和已拒绝的决策维护只追加的台账，这样未来的智能体就不会重新发现那些已经被排除的路径。 任何调用付费或有速率限制的API的循环，在运行前都必须具备三个特性：有限的并行度、能跳过已完成工作的恢复能力，以及能在单次调用内暴露停滞状况的逐次运行进度记录。在第一次付费调用之前，要设置明确的成本上限或运行次数上限。 ## 用同一个种子重跑基准测试，并与基线对比 对于基准测试和评估工作，要重视严谨性而非速度：统计上的严谨、偏差的缓解、消融实验和可复现性。通过使用相同的随机种子和测试固件重复运行，让质量变得可衡量、结果具备可比性，并公布相对于基线的差值，而不是只给出一个孤立的数字。 汇总准确率是一个容易产生误导的指标；应报告逐项的效应量和混淆矩阵，以便看清行为究竟在哪些地方发生了变化。对于任何必须保持安全的场景，都要保留对抗性测试用例，并且每当发现一种新的失败模式，就为其新增一个测试场景，以防止它悄无声息地再次出现。