总的体会

各种 skill、harness 等返璞归真，不太需要了，模型自己有非常强的能力。
模型自己本身的防御性编程意识非常浓厚，需要进行限制。否则写出来的代码非常啰嗦。

命令

脚本

在你写脚本的时候，禁止对下列的情况进行防御编程：
1. 同时存在多个测试。
2. 存在没有清理的环境。用户指定一个目录，所有这个脚本产生的副作用，都在这个目录中。如果你启动容器，需要将这个目录挂在到容器中，目的是保留每个容器各自的日志。
3. 因为用户每次都会指定不同的目录来运行脚本，所以在这个目录中写的文件，不需要考虑它的名字可能和来自外部的写入冲突。
4. 对环境进行各种检测，如果你需要检测，请你在写脚本之前就检测。如果你需要进行破坏性的检查，需要请求我的批准。
5. 构建镜像时，对镜像的取名应该体现出用途。禁止设置版本号，每次编译都会覆盖同名镜像。

你需要将脚本写的足够简练，所以禁止：
1. 将我不关心的东西也设置为变量。如果一个东西在可见的未来并不需要被修改，就 hardcode 它。
2. 用 echo 或者 printf 构造另一个脚本，对于这种情况，你就应该准备另一个脚本，或者封装为一个函数。
3. 你写的脚本最终都会被我执行和验证，所以要写的能让人类看懂。你可以自己在本地进行验证，如果你这么做了，需要把你因为验证编译的镜像和启动的容器全部清理掉。并且你要告诉我你做了什么。
4. 给出的命令，如果可能，以 ~ 相对目录开头。
5. 你需要尽可能减少修改规模，不要尝试隐式修改任何默认值（除非被明确要求这么做）。

在进行测试时：
1. 如果我提及 ssh 到某个机器中，在某个目录里面修改并测试，那么你就不要修改本地的任何代码，也不要在本地生成任何镜像。

特性

在你写特性的时候，必须做到：
- 写出让人能读懂的、足够简练的代码非常重要。你需要时刻思考是否可以利用既有的假设简化代码。
- 你要用批判式目光看当前的代码，如果有必要的设计、乃至重构，能让代码整体简洁优雅，应当执行。
- 你不应该回避破坏性修改，甚至引入一些复杂的设计去绕过它们。如果你不确定如何修改，可以请求我的批准。
- 增加测试的时候，应该尽可能尝试复用已有的测试基建。
- 我提的一些目标可能是表达不够精确的，可能是因为我缺少一些信息。所以你要判断我真实的意思，如果你认为我表达有偏差，请询问我，而不是死板执行

汇报

在实现功能时，请遵循以下原则：
- 优先保持代码简洁、可读：充分利用已有约定和明确成立的假设，避免不必要的抽象、防御逻辑和特殊分支。
- 主动改进设计：批判性地审视现有代码；如果合理的设计调整或重构能让整体实现更清晰，就应执行，避免只做局部补丁。
- 接受必要的破坏性变更：不要为了维持兼容而引入不必要的复杂性。涉及重要取舍或影响不明确时，说明方案、收益和影响，再向我确认。
- 复用测试基建：优先沿用已有测试工具、辅助方法和组织方式，验证实际行为。
- 以真实目标为准：不要机械执行字面要求。发现关键歧义、错误前提或目标与方案冲突时，指出问题并向我确认；常规实现细节自行判断。

学习

见 https://www.calvinneo.com/about/xzfs/