pstack原则08边界纪律：如何把守卫放在系统边界，内部信任类型-二趣网

pstack原则08边界纪律：如何把守卫放在系统边界，内部信任类型

【免费下载链接】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 等 Agent 运行时的意见化技能栈（skill stack），其中"边界纪律"（Boundary Discipline）是它的核心架构原则之一：验证、类型收窄与错误处理集中放在系统边界，内部代码无条件信任类型。理解这一条原则，能帮你写出更简洁、更好测的 Agent 工作流代码。

为什么需要"边界纪律"

🛡️ 新手写代码时最容易犯的一个错误：到处加验证。

在函数 A 里判一次空，函数 B 里再判一次，调用链深处还塞满了if (x == null)。看似安全，实则带来三个问题：

噪音大：真正的业务逻辑被防御性检查淹没
冗余：同一份数据被反复校验，白白消耗性能
虚假安全感：检查散落各处，反而没人说得清"到底哪里保证了数据合法"

pstack 的边界纪律原则给出一个清晰答案：守卫只放在边界，内部一律信任类型（源码见 principle-boundary-discipline/SKILL.md）。

三层心智模型：把守卫摆对位置

这个原则的完整模式可以拆成三层：

1️⃣ 在边界上（At boundaries）

凡是数据进入系统的入口——CLI 参数、配置文件、外部 API、网络协议——都要验证、报错、防御性处理。这是唯一应该"怀疑数据"的地方。

2️⃣ 在系统内部（Inside the system）

边界之内只有类型化数据和错误传播，不再重复验证。信任类型系统，让编译器替你把关。

3️⃣ 跨越边界时（Across the boundary）

对外暴露领域概念，而不是边界层的私有表示；把通用机制留在内部，把专用策略放在边缘。

💡 一句话记忆：进门严查，进门之后互相信任。

具体落地：验证放在哪里、逻辑放在哪里

SKILL.md 给出了两条落地清单：

验证与错误处理

配置在解析时（边界）就校验，而不是等到业务逻辑里才发现
在边界处把原始数据解析成领域类型（parse into domain types）
不要通过公共 API 再导出传输层、存储层或框架的私有类型
边界已验证过的数据，调用链深处不再重复判空

代码组织

业务逻辑写成纯函数，不依赖框架——这样才能脱离框架独立测试
解析函数：从原始字节到类型化状态的纯转换
提示词构建：结构化的状态进，字符串出

这与姊妹原则"类型系统纪律"紧密配合：外部数据在解析前是无类型的，每个边界都应有一个 parse 函数把它转成类型化模型（见 principle-type-system-discipline/SKILL.md）。两条原则合起来就是：边界做转换，内部做信任，编译器做证明。

什么时候该想到这条原则？

在 pstack 的poteto-mode技能编排中，边界纪律被登记在"架构"类原则下，触发时机明确（见 poteto-mode/SKILL.md）：

场景	该做的事
接线验证逻辑、错误处理	检查验证是否发生在边界，而不是散落在业务里
编写框架适配器	让适配器（壳层）保持"薄且机械"，逻辑不外泄
代码审查发现层层判空	问一句：边界校验过了吗？过了就该删掉

它还会被架构审查引用：例如设计红旗检查会追问"这个转发层是真正的边界，还是多余的包装"（参考 design-red-flags.md）。

两个自检问题（Two Tests）

🔍 判断某段验证该不该存在，pstack 给出了两个极简测试：

"这份数据现在正跨越系统边界吗？"如果不是——这个验证就是冗余的，删掉。
"这段逻辑能否抽成一个纯函数，让壳层直接调用？"如果能——抽出来。

只要养成这两个反射，你的代码会逐渐变得"边界厚、内部薄"：好读、好测、改动时不慌。

企业官网建设流程全解析