ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

pstack 实战:让 Agent 先构建改动、再清理出可评审的 diff

pstack 实战:让 Agent 先构建改动、再清理出可评审的 diff pstack 实战让 Agent 先构建改动、再清理出可评审的 diff【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/pluginspstack 的构建类 playbook 共享同一条纪律先说出你观察到了什么再让 playbook 用证据来约束后续每一步。本文以 05-build-and-clean.md 为主线讲解如何在 poteto-mode 下为 Bug 修复、功能开发、重构、性能优化四类任务写出高质量的 slash 命令 prompt如何用/tdd让失败测试先行如何借助typescript-best-practices让类型规则自动生效以及如何在提交前用/deslop、/unslop、/no-comments三件套把 diff 和 PR 文案清理到可评审状态。读完你将掌握一套可以直接套用的命令模板与底层执行逻辑让 Agent 产出证据充分、注释干净、diff 可读的提交。构建类 playbook 的共同纪律观察先行证据约束pstack 的构建 playbook 之所以有效是因为它们把你懒得敲的那些步骤内置在了 skill 里。你在 prompt 中只需陈述已知事实症状、期望行为、约束、测量值playbook 会自动补齐关键流程修复前先复现、实现前先命名数据形状、重构前先钉住行为、优化前先做剖析。对应的 playbook 文件位于 pstack/skills/poteto-mode/playbooks/ 目录下。Bug 修复 prompt先给症状要求复现/poteto-mode this command emits two records after a retry. repro first, then fix and verify./poteto-mode会将该请求路由到 bug-fix.md playbook。打开源码可以看到它强制要求六步科学流程在匹配的表面上亲自复现通过对应的 control skill不把复现工作丢给用户无法直接复现时就合成触发条件、收紧条件或加埋点直到它触发。二分排查根因形成候选假设后逐一排除每一轮都用运行时证据消除而不是猜测。规划修复跨函数边界先走architect再把实现委托给子代理。在同一个表面上验证原复现用例通过才算过inconclusive 或验证面不对都不算通过。提交时让失败的复现用例先落在 git 历史里修复再落在其上这正是sequence-verifiable-units原则的典型应用。最后执行 Opening a PR。每行代码都必须能追溯到运行时证据也许有用的双保险属于假设而非修复不会合入。功能开发 prompt说明行为与不可变项/poteto-mode add a --json flag. text output stays byte-identical. verify both forms.该请求路由到 feature.md。playbook 的第一步用how理解受影响子系统第二步用architect做并行设计探索跳过必须在 todo 中写明architect skipped: reason第三步写吞吐量检查点throughput checkpoint包含四项 todoBlocking first steps.扇出前的门禁检查。Independent workstreams.互不相交的文件、服务或层可以并行共享写入必须串行。Shared mutable state.默认拆分目标仅为真实不变量做串行化。Smallest safe decomposition.若单 worker 最优要说明原因。实现委托给子代理时必须带上文件路径、命名的数据形状及其组织结构按model-the-domain原则选择状态机替代散落的布尔值、表/注册表替代分支、类型化模型替代重复的形状假设、以及成功标准。当实现存在多种合理形态时通过arenaskill 让多个候选方案竞争由交叉评审守护最终选择。这一步不允许用 app 太小 之类的理由跳过。重构 prompt先钉住行为再动结构/poteto-mode move parsing into one module, zero behavior change. record the current output first and prove its unchanged after.路由到 refactoring.md。它的核心契约是结构可以变行为不能变第一步就是钉住行为契约用how学习契约后写特征测试、快照或等价性 harness 来捕获当前行为类型检查和 lint 都不算钉住。随后命名缺失的结构、命名目标形态、先减法后加法删死代码、折叠单调用方 wrapper、去掉冗余校验再以小步保持行为不变的方式移动最后用等价性证明旧新输出 diff、回放基线、同表面冒烟运行验证真实产物。若重构暴露出缺失功能或真实 Bug拆出去单独处理先合入保持契约不变的结构性改动。性能优化 prompt给测量值不要给感觉/poteto-mode startup takes 1.8s on this fixture. trace it, fix the measured cause, show me before and after.路由到 perf-issue.md。它要求你拥有测量故事先用匹配的 control skill 抓基线 trace用how落地假设修复后抓 post-fix trace 并解析对比产物最后在 PR 中引用测量数字。playbook 内置了八类策略族作为假设生成器而不是清单Elimination热路径是否根本不该存在、Divide and conquer、Caching、Indirection、Batching、Redundancy、Lazy evaluation、Scheduling。每个策略族只有在 trace 显示出对应信号时才值得尝试。Hillclimb针对单一指标的持续爬坡如果目标是持续改进同一个数字而非一次性修复使用 hillclimb.md playbook。给它指标、目标和尝试次数下限它就会用冻结的测量 harness 一次只循环一个假设核心纪律是一个改动、一次测量、保留或回滚绝不叠加未经测试的改动。先确定真实的工作负载维度选一个能复现用户抱怨的用例修复一个指标明确更好的方向以及成对出现的停止谓词目标 尝试次数下限防止一次侥幸的早胜提前结束实验例如至少比基线好 50% 且至少迭代 10 次。构建测量 harness证明其灵敏度后冻结它一个可重复的命令发出指标用中位数采样压过噪声。每个被接受的修复一个提交只暂存改动文件git add files绝不-A通过 show-me-your-work skill 维护决策日志decision.tsv一行一条尝试记录id、假设、改动、before、after、delta、测试、verdict。只有指标移动超过噪声且回归门保持绿色才接受否则整体回滚可能有用的微调不留。遇到平台期就换类别、合并接近命中、重读源码但正确性与简洁性优先于数字。用/tdd让失败测试先行当 Bug 有一条廉价的本机测试路径时整个 prompt 可以只有两个词/tdd implement在上下文中这已经足够。它路由到 pstack/skills/tdd/SKILL.mdskill 会先写出能因预期原因失败的最小测试再写修复再重跑测试。其完整工作流是理解 Bug意图行为、当前行为、受影响路径、最小可观察复现→ 选择最窄的可执行检查优先该代码路径已有的单元/组件/集成/回归测试→ 先写失败测试编码意图行为而非镜像当前实现→ 修复前运行新测试确认它因预期原因失败 → 做最小生产改动 → 重跑回归测试确认通过 → 跑邻近验证相邻测试、类型检查、lint。skill 明确设了护栏如果测试需要广泛的 harness 搭建、脆弱的 mock、慢的端到端基础设施、仅生产环境的状态、模糊的复现步骤或大量无关 fixture 变更就跳过新增测试改用最接近的可执行检查定向脚本、手动复现命令、浏览器自动化、快照对比、日志断言、聚焦集成检查并显式说明原因而不是静默跳过。宁可不加测试也不要坏测试一个主要测 mock、编码当前实现细节、依赖时序或全局状态、或证明完修复就要删掉的测试属于坏测试。这正是原文Dont force a test where a real command is stronger evidence的出处真实命令是比脆弱测试更强的证据。让 TypeScript 规则自动加载typescript-best-practices 在你的工作流里没有斜杠命令。它在 Agent 触碰.ts或.tsx文件时自动加载skill 头部声明了paths: [**/*.ts, **/*.tsx]把类型系统原则变成具体规则。核心规则表如下规则摘要Discriminated unions用带kind字面量判别式的变体建模让非法状态无法被表示不用可选字段袋。Branded types用 { readonly __brand: X }为原始类型打品牌避免混用在边界处只验证一次。Constructive modeling构造出使非法值无法产生的形状如非空数组用[T, ...T[]]而不是运行时守卫。Simplest total type只要T[]上的操作保持 total 就用它仅在宽松类型逼出!、cast 或 should never happen 抛错时才加强。unknownoverany外部数据一律是unknown。Schemas before guards手写逐属性类型守卫前先用仓库的运行时 schema 库并从 schema 推断类型如z.infer。Noascasts每个as都是一次等待发生的运行时崩溃只在验证后 cast。Narrowing hierarchy判别式 switch in操作符 typeof/instanceof 用户自定义守卫 as。Type guards守卫必须验证其声称的内容命名用isX/hasX撒谎的守卫比as更糟。Exhaustiveness在 default 分支写const _exhaustive: never x;新增变体时让编译器报错。satisfiesoveras验证值而不扩大字面量类型。Boundary validation数据跨入边界时解析为命名的领域类型Recordstring, unknown到解析处为止内部信任类型。Schema-derived types声明新 interface 前先考虑Pick/Omit/Parameters/ReturnType/Awaited/typeof。Object args传对象而非位置参数热路径每帧渲染、tokenizer、parser除外。Real tests不 mock 能跑的东西优先框架真实测试原语只在无法本地运行时才 mock。Structured telemetry用带足调试上下文的结构化日志合入代码中不出现console.log。规则示例见 references/patterns.md。这意味着你不需要在每次任务里显式叮嘱用判别式联合只要工作涉及.ts/.tsx这些规则就会作为上下文约束生效。提交前清理/deslop与/unslopopening-a-pr.md playbook 会在每个其他 playbook 的末尾被调用要求在每个提交前对 diff 运行/deslop并对 PR 描述和提交正文应用/unslop。/deslop随cursor-team-kit插件发布见 cursor-team-kit/skills/deslop/SKILL.md不在 pstack 内。如果没有安装它用大白话请求同样的结果删除叙述性注释、无依据的守卫、死掉的兼容路径和无关改动。针对散文prose/unslop接受一个目标和你附加的任何规则/unslop the readme changes, no emdashes它会扫描并消除 AI 痕迹表面化的-ing短语、模糊归因、AI 词汇additionally、crucial、delve、underscore 等、花哨的 is 说法、not just X but Y、三连排比、破折号滥用、标题大小写、装饰性 emoji、聊天机器人套话、填充短语、过度含糊、抽象隐喻名词、以及说感觉不说机制的表达。它甚至规定了短破折号字符在回复中不允许出现poteto-mode 的写作纪律之一。你会逐渐形成自己的速记skill 能从容读懂的 prompt 可以是unslop that, tighten it这样简练的句子。用/no-comments剥离注释注释需要单独一轮清理而且不能交给写它们的那个人作者会像维护自己的孩子一样维护自己的注释。所以在评审之前把它交给一双没写过的眼睛/no-comments the diffno-comments 会派生 Comment Sicko一个只读评审者其豁免名单keep list非常短法律/许可证头。公共 API 上的文档注释。解释代码无法表达之事的 Issue/RFC 链接。由你无法重塑的外部依赖、平台、厂商或协议强制的非显然行为你自己代码里的意外surprise得不到豁免会带着重构标记MUST KILL被打回来。其余全部删除。当注释声称某个约束do not remove时skill 会提议把该约束编码为类型、测试或 lint无论接受与否注释都会消失。完整的执行步骤是派生 Comment Sicko 并传入范围 → 检查其报告与 diff拒绝应用代码改动、越界、受异常保护的删除、误述的MUST KILL理由→ 直接修复已接受的琐碎 flag删除死路径、去掉参数、改用真实 API需要形状时先跑一次architect停在草图 → 实现范围内最小的根因修复绝不外挂症状守卫 → 对约束注释提供最廉价的范围内的类型/运行时/测试/CI lint 编码等交互批准后先编码再删除 → 汇报删除数、恢复的注释、重跑、架构草图、修复、编码、未强制执行的约束。三件套的分工与陷阱分工值得记清楚/deslop负责清掉代码里的 slop/unslop负责清掉散文里的 slop/no-comments把注释交给没写过它们的人评审。一个常被忽略的陷阱清理不是可选的润色。带叙述性注释和防御性死重量的 diff在评审者眼里等于没做完而多出来的代码正是下一个 Bug 藏身之处。如果 diff 感觉臃肿在提交前就说deslop it而不要等评审指出来再补救。提交阶段还有配套规范提交要小而有序每个提交都是未来的 PR可单独落地、按序讲述故事PR 标题用 Conventional Commits 形式type(scope): subject如fix(pstack): retarget opening-a-pr babysit triggerPR 描述按 Why / Scope / Tradeoffs / Blast Radius / Verification 顺序组织性能改动必须以before → after形式报告一个带单位的主数字。关于 PR 全流程worktree、forge 选择、栈式 PR、babysit 触发条件的细节都在 opening-a-pr.md 中。至此你的每次构建都遵循同一套路径用一句话陈述观察 → 让 playbook 索要证据 → 失败测试先行 → 提交前清理 diff 与文案 → 交给独立评审。下一步是验证与合入Verify and ship。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表