企业官网建设流程全解析

pstack原则03第一性原理重设计：新需求如何融入现有架构

【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Poteto's pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claude

pstack 是一套面向 Claude Code、Codex、Pi 等智能体框架的工作流技能栈，其中「第一性原理重设计」（Redesign from First Principles）原则专门回答一个让很多开发者头疼的问题：新需求来了，为什么总是变成"往老代码上打补丁"，而不是像从一开始就在架构里一样自然融入？本文用这个原则讲清楚：不做堆叠式修改的前提下，新需求应该如何融入现有架构。

为什么"顺手加上去"的新需求会毁掉架构

大多数团队加新需求的方式是"贴上去"（bolt-on）：找到最相关的文件，塞一个字段、加一个分支、打一个特例。短期成本最低，长期代价却是：

• 🧩引用不同步：类型、文档、示例、设计理由还停留在旧设计，代码与说明互相矛盾
• 🌀特例蔓延：同一个 if 分支在多处重复出现，下一个改动者不知道哪些是"主干"、哪些是"补丁"
• 📉复杂度复利：在复杂系统上继续添加，只会让复杂度以乘法增长

pstack 对该原则的定义只有一句话（见 principle-redesign-from-first-principles/SKILL.md）：

When integrating a change, don't bolt it onto the existing design.Redesign as if the requirement had been there from the start.（集成变更时，不要把它钉在现有设计上。要像这个需求从一开始就存在那样重新设计。）

新需求融入现有架构的4步方法

原则正文给出了可直接照做的四步流程：

1. 通读所有受影响文件，真正理解当前设计，而不是只看报错位置
2. 问出关键问题："如果我们带着这个新需求从零开始写，会构建什么？"
3. 把变更传导到每一处引用：类型定义、文档、示例、设计理由说明，全部更新，不允许只改实现
4. 先想完整体重设计，再增量交付：设计必须是全局自洽的，落地则可以分小步，每一步可验证

第 4 步最容易被误读成"推倒重写"。pstack 的意图恰恰相反：重设计是思维动作，交付仍然是小步验证的单元——这与它的「Sequence work into verifiable units」原则（principle-sequence-verifiable-units/SKILL.md）一脉相承。

不是单打独斗：配合原则03的原则组合拳

在 poteto-mode/SKILL.md 的原则清单里，「Redesign from First Principles」被列为核心原则之一，它从不孤立生效：

• 🔍基础先想（principle-foundational-thinking/SKILL.md）：先定核心类型和数据结构，逻辑自然浮现；重设计时必须重新回答"数据形状是什么"
• ➖先减后加（principle-subtract-before-you-add/SKILL.md）：先删掉死代码和冗余校验，在新需求落进更简单的地基之前，新设计应该比旧设计更小
• 🎲穷尽设计空间（principle-exhaust-the-design-space/SKILL.md）：新需求没有先例时，至少做出两个结构性不同的候选方案再收敛，"第一种方案的换皮版不算第二个"
• 🧱用结构建模领域（principle-model-the-domain/SKILL.md）：判断重设计是否到位的标准——新需求是让 if/else 链又多了一枝，还是落进了正确的数据结构里

实际项目里如何触发这套流程

pstack 的路由规则（见 poteto-mode/SKILL.md）很明确：只要改动跨越函数边界，就进入 architect 技能（architect/SKILL.md），它把第一性原理重设计落成了五个阶段：

1. Ground：用 how 技能对受影响的子系统建立心智模型，"说出文件名不算理解"
2. Sketch：用 arena 并行产出多个结构不同的设计草案
3. Agree：可选的人工检查点，默认直接实现
4. Implement：按选定草案实现，偏离草案是信号，要显式上报
5. Scrap：当"同一种绕行方式反复出现"、"需要 any/强制转换才能编译"等模式化信号出现时，扔掉草案重来——重设计，把新约束当作第一天就存在的假设

注意 Scrap 阶段的判断标准是模式而非个例：个别边缘情况不会否定一个架构，但同一种绕行在无关代码里反复出现，就是设计错了的证据。

参考资料

一句话总结：新需求不是"加到架构上"的，而是"重新长出架构"的。先通读、再问"从零会怎么设计"、传导到所有引用、增量交付——四步走完，补丁式修改自然消失。

【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Poteto's pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claude