把反复踩坑沉淀成AI编程技能

给 AI agent 写了很长的规则，它仍然跳过复现、改完不验证，怎么办？这篇文章借 pstack 给出的答案是：把反复发生的错误沉淀成可执行流程，再要求 agent 带着证据交付。

值得借鉴的不是它有多少个 skill，而是它如何串起任务分派、完成标准和项目验证。不过，原文提供的主要是仓库结构与文档说明，没有证明这套方法能提升多少成功率。读它更适合拿走工作方法，而不是寻找效果承诺。

58 个 skill，怎样才能用到当前任务上

据作者在 2026 年 10 月 25 日对 cursor/plugins 仓库的核对，pstack 包含 58 个 skill、23 份 playbook 和 24 条 principle。这里不能把三个数字相加：24 条原则包含在 58 个 skill 中，其余约 34 个承担技术写作、benchmark 检查、文字清理等具体工作；23 份流程手册则独立存放。

它们的统一入口是 /poteto-mode。用户描述目标，agent 从 23 份 playbook 中选择适合的流程，把步骤复制到任务列表，再按步骤调用其他 skill。

这解决的是一个实际问题：规则即使写得齐全，也得在正确的时机被调用。修 bug、增加功能、调查原因，需要的步骤并不相同。

流程还要求保留被跳过的步骤，并注明 skip: <reason>。用户因此能看到某项检查为什么没有执行，而不只是收到一句「已经完成」。

原文转述 Lauren Tan 的经历说，pstack 并非一开始就按产品设计，而是逐步吸收重复失败的教训：改代码前先复现、提出多个假设并逐一排除、先写失败测试、检查 diff 之外的影响，以及保留修改前后的真实画面。

值得复制的是修正流程的方式，不是 58 这个数量。

把「帮我优化」变成能够验收的任务

pstack 文档建议，一个任务提示最多包含五项，每项用一句话交代：目标、完成标准、希望看到的证据、已知信息，以及真实约束。

其中，完成标准和证据最容易混淆。前者回答「怎样才算完成」，后者回答「拿什么证明完成」。页面能打开，不代表交互正常；agent 声称性能改善，也不等于提供了测量结果。

原文用下面这个泰文提示演示如何把滚动卡顿变成可检查的任务。它是作者补充了假想背景的示例，并非真实测试记录：

/poteto-mode หน้าตั้งค่ากระตุกเวลาเลื่อนรายการ
เริ่มตั้งแต่ deploy เมื่อวาน ผู้ใช้ 2 คนแจ้งใน Slack
ทำซ้ำก่อน แล้วค่อยแก้
เสร็จเมื่อเลื่อนรายการ 200 แถวแล้วไม่มีเฟรมตกเกิน 16ms
ขอวิดีโอก่อนกับหลัง และตัวเลข frame time

要看的是包含 200 和 16ms 的那一行：它尝试用滚动 200 行列表时的帧耗时设定验收门槛，同时要求修改前后的视频与 frame time。前面的「昨天 deploy 后出现」「2 位用户在 Slack 反馈」都是示例背景，不能当作线上事故或优化成果。

文档还建议省略用户预设的实现方法和原因猜测，避免 agent 围绕一个未经验证的判断反复搜索。对于描述混乱的问题，先让 agent 用自己的话复述，理解偏了可以在写代码前纠正。

这个建议需要区分事实和猜测。错误日志、复现步骤、已有调查结果应当提供；尚未证实的原因，可以明确标成假设。否则，为了不给 agent 暗示而删掉有效信息，同样会增加调查成本。

项目验证要写到陌生 agent 也能执行

pstack 的 create-verification-skill 用来生成项目专属的验证说明，让 agent 启动真实应用、操作功能并保存证据。

它强调先「采访仓库」，再考虑问人。应用如何启动、用户会操作哪些界面、agent 用什么工具驱动、证据保存在哪里、能否同时运行两个实例，这些问题应先从代码和配置中寻找答案。

验证说明的读者，是下一位刚打开仓库、完全不了解项目的 agent。因此，「启动后检查一下」不够，它需要能照着执行的步骤和判断标准。

另外三条原则补上了流程的边界：

• principle-encode-lessons-in-structure 要求尽量把规则落实为 lint、metadata flag、runtime check 或脚本，减少对文字提醒的依赖。
• principle-test-behavior-not-implementation 要求测试关注行为，避免内部实现一重构，测试就跟着失效。
• principle-never-block-on-the-human 鼓励 agent 自主完成可撤销的工作；force push、删除生产数据、向组织外发送消息等操作仍须许可。

这 24 条原则分别作为 skill 保存。按原文描述，/poteto-mode 会在开始多步骤任务时读取索引，并在回答中引用实际使用的原则。

我的判断

我赞同它把交付要求从「给出修改」推进到「给出可检查的修改」。对于前端工作尤其如此：diff 能帮助审查代码，但交互是否走通、页面是否出现异常，还需要运行应用才能确认。

不过，原文没有提供采用前后的成功率、耗时或成本对照，也没有证明 skill 比一次写好的长提示更有效。仓库数量是作者报告核对过的信息；关于效果的结论，更多来自 Lauren Tan 的经验与作者的判断。这篇原文本身也注明由 deepseek-v4.1-flash 经 ollama-cloud、通过 Hermes Agent 撰写，并由人类监督和质检，这些信息不构成额外的效果验证。

与统一维护一份项目规则文件相比，拆分 skill 有利于按需调用，但也增加了路由和维护成本。与自动化测试相比，验证 skill 能描述启动、操作、取证的完整流程，却仍依赖环境可用、工具可驱动、结果可判断。

示例中的 16ms 也不能直接成为所有项目的性能标准。原文没有交代设备、浏览器、采样方式或统计口径。没有一致的测量条件，前后数字很难可靠比较。

规则能由工具检查时，就应尽量交给工具检查。

能拿来做什么

• 从修 bug、增加功能、调查问题三种流程开始，给 agent 一个统一入口，并要求跳过的步骤保留理由。先观察实际遗漏，再决定是否拆出更多 skill。
• 为前端项目写一份可执行的验证说明，交代启动方式、关键操作、成功标准和证据位置，让新进入仓库的 agent 能独立完成基本检查。
• 提交 AI 编程任务时，补齐已知症状、完成标准和所需证据。性能任务还应写明测量条件，避免只交付一组无法比较的数字。
• 每次出现重复错误，只补一条针对性的流程或检查。能转成 lint、测试或脚本的规则优先自动化，其余再写入 skill，并说明适用条件。