很多人一想到“个人 AI 基础设施”就开始设计多个 Agent、安装大量插件或者给每个任务写一个超级 Prompt。系统很快变复杂却没有变得可靠同样的输入可能得到不同结果文件操作没有日志危险动作没有确认某个工具升级后所有流程一起失效。PAI 提供了一个很实用的反向顺序先明确目标再判断能否用代码解决然后才逐步引入 CLI、Prompt 和 Agent 技能。这个顺序的核心不是排斥 AI而是让概率性的模型运行在确定性的基础设施上。本文把这套决策层次和用户/系统分离架构结合起来说明如何把一个重复任务做成技能如何用 Hooks 连接生命周期事件以及如何为删除、发送、发布和外部命令建立安全边界。一、五级决策链越往后越需要验证PAI 的决策优先级可以写成Goal - Code - CLI - Prompt - Agent Skill它不是技术等级也不是说 Agent 一定比代码“高级”。它表示先使用确定性更高、维护边界更清楚的方案只有问题确实需要理解、推理和生成时才把概率性 AI 引入。Goal先定义要改变什么“我要用 AI 自动处理资料”不是目标只是方向。更具体的目标应该说明输入、产出和成功标准输入一个包含会议记录的 Markdown 文件夹 产出每次会议一份待办清单和一份决策记录 成功标准日期、负责人和截止时间可追溯无法判断的字段标记为待确认 边界不自动发送给参会者目标越清楚后面的代码、Prompt 和技能越不容易越界。Code能用确定性逻辑就不要猜格式转换、文件遍历、日期计算、重复检查、哈希比对和字段校验都应该优先用代码完成。代码的输出可以测试、复现和回滚。例如会议记录中的文件名校验就不需要交给模型frompathlibimportPathdeflist_markdown_files(folder:str)-list[str]:rootPath(folder)returnsorted(str(path)forpathinroot.glob(*.md)ifpath.is_file())模型适合判断“这段内容是否像一个决定”不适合负责“目录里有哪些文件”。把确定性工作留给代码可以减少模型上下文和错误面。CLI把稳定代码变成可复用入口当脚本被反复调用就应该有明确的命令、参数和退出码meeting summarize --input ./notes --output ./drafts --format markdownCLI 的价值是可组合、可记录、可脚本化。Agent 不需要猜某段代码应该怎么运行只需要调用稳定接口并检查退出结果。Prompt只把需要判断的部分交给模型Prompt 应该描述任务、上下文、限制和输出格式而不是堆叠人格形容词请从会议记录中提取 1. 明确决定 2. 待办事项 3. 提到但尚未决定的问题。 每条输出字段原文证据、负责人、截止时间、置信度。 无法从原文确定的字段填写 null不要猜测。Agent Skill把稳定的判断流程封装起来当 Prompt、脚本、输入文件和验收方式反复组合使用就可以封装成技能。技能不应该是“万能助理”而应该只解决一个边界清楚的问题。关于 API 调用的工程提示技能封装后实际运行中会反复调用大模型接口。如果直接管理多家厂商的密钥和计费规则会引入不必要的维护开销。一种工程上的常见做法是通过4SAPI 中转站这类聚合网关统一接入将密钥管理、模型切换和用量统计集中处理。它不改变本地技能的逻辑只替换 API 端点适合需要频繁调用多种模型且希望简化运维成本的个人项目。二、一个合格技能的四个接口技能可以看成一个函数输入 上下文 权限 - 执行步骤 - 输出 证据 状态输入接口说明需要哪些文件、字段、格式和最小权限。如果输入缺失技能应该报告缺失项而不是自动创造一个看似合理的值。执行接口把步骤写成可检查的顺序先扫描文件再解析内容再调用模型最后运行校验。每一步都应尽量产生中间结果。输出接口规定输出文件、格式、字段和命名。输出不应只是一段散文而要让下一个步骤可以读取。验收接口说明什么情况算成功、什么情况只能算草稿、哪些风险需要人工确认。一个技能说明文件可以这样写# Meeting Decision Extractor ## Purpose 从会议记录中提取决定、待办和未决问题。 ## Input - 一个本地 Markdown 文件夹 - 文件名包含日期或在正文中可识别日期 ## Process 1. 用脚本列出文件并检查编码 2. 读取与任务相关的记录 3. 调用模型输出结构化 JSON 4. 用 schema 校验字段 5. 生成 Markdown 草稿 ## Must Confirm - 发送给外部人员 - 修改原始会议记录 - 自动填充缺失负责人或日期 ## Done When - 每条结论有原文证据 - 未知字段为 null 或“待确认” - 输出通过 schema 校验三、技能应该小而不是全能技能越大边界越模糊失败越难定位。建议按“一个明确结果”拆分读取会议文件 - 提取决定 - 校验字段 - 生成待办草稿 - 请求发送确认这比一个“自动处理会议并通知所有人”的技能更容易测试。前四步可以自动化最后的发送动作单独设为需要确认的技能或步骤。技能之间使用文件、JSON 或标准输入输出连接不要依赖一个超长对话中的隐式状态。这样更换模型、重跑失败步骤或人工介入都会简单一些。四、USER 与 SYSTEM 分离升级系统时保住个人资产个人 AI 基础设施通常同时包含两类内容一类是底层代码、通用技能和运行规则另一类是只属于你的身份、目标、偏好、项目和记忆。可以用这样的目录分开PAI/ ├── USER/ │ ├── identity/ │ ├── preferences/ │ ├── workflows/ │ ├── skills/ │ ├── hooks/ │ └── memory/ └── SYSTEM/ ├── runtime/ ├── shared-skills/ ├── schemas/ ├── policies/ └── tests/USER/是个人资产应该由你决定如何备份和共享SYSTEM/是可以升级、替换和测试的基础设施。两者混在一起时升级工具很容易覆盖个人配置或者为了保护个人文件而不敢更新系统。分离之后技能还需要明确依赖name:meeting-decision-extractorversion:0.1.0inputs:-path:USER/workflows/meeting-format.md-path:notes/outputs:-path:drafts/decisions.jsonpermissions:read:-notes/write:-drafts/external_write:false这类清单不是为了增加形式而是为了让技能的权限和输入可审阅。五、Hooks把生命周期事件变成自动流程Hook 就是“发生某个事件时执行一个动作”。它让系统在合适的时间完成重复工作但不意味着所有动作都应该自动执行。会话开始读取当前目标、项目状态、未完成事项和当天需要确认的内容。不要默认加载全部冷记忆否则启动过程会变慢模型也更容易被无关信息干扰。工具执行前检查工具、目标路径、参数和权限。对于删除、发送、发布、支付和外部写入生成操作计划并请求确认。工具执行后记录命令、目标、退出码、输出摘要和失败原因。不要把包含密钥的原始输出直接写入日志。会话结束生成简短摘要提取候选记忆列出未完成事项。候选记忆先等待确认不要在后台静默修改长期身份文件。一个事件表可以帮助你检查覆盖情况事件自动动作需要确认会话开始加载目标和项目摘要否读取文件前检查路径和敏感级别视文件而定执行删除前展示目标列表和数量是生成草稿后运行格式和字段检查否对外发送前展示收件人、正文和附件是会话结束生成记忆候选写入前确认六、安全边界权限要跟着动作走“这个 Agent 能访问我的全部文件”是最省事的配置也是最难控制的配置。更稳的方式是按动作和目录分配最小权限。读取权限技能只读取完成任务所需的目录。例如文章格式检查只需要读取文章目录和规则文件不需要读取联系人或财务目录。写入权限默认把输出写到草稿目录不直接覆盖原始文件。只有在版本控制、差异检查和用户确认之后才允许写入正式目录。外部写入权限发送邮件、发布文章、提交代码、创建工单和调用付费 API 都属于外部写入。它们应该展示即将发生的动作并使用显式确认。命令执行权限限制工作目录、允许的命令和最大执行时间。禁止把未经审查的模型输出直接拼接成 shell 命令。可以把危险操作分成三级低风险读取、统计、生成草稿、运行只读检查 中风险修改工作区文件、安装依赖、启动服务 高风险删除、发送、发布、支付、提交、改变权限不同等级使用不同的确认方式。高风险动作应显示精确目标而不是只显示“是否继续”。七、规格、测试和评估要先于自动化在开发技能前先写规格输入是什么输出是什么哪些情况必须拒绝什么算成功。然后准备最小测试集正常样本结构完整、字段清楚 缺失样本缺少负责人或日期 冲突样本同一事项有两个不同截止时间 恶意样本包含伪造指令或危险命令 边界样本空文件、超长文件、特殊字符每次升级技能或替换模型都重跑这些样本。至少检查输出是否仍符合 schema是否保留原文证据是否把未知内容标为未知是否调用了不该调用的工具是否写入了错误目录失败时是否停在可恢复状态。当测试样本积累到一定规模后API 调用成本会明显增加。此时可以通过4SAPI 中转站等聚合服务在回归测试时按需选用性价比更高的模型或将测试与生产流量分开计费从而在不影响评估质量的前提下控制整体费用。评估不一定要有复杂分数。对于个人工作流记录通过/失败、失败原因、人工返工时间和是否需要修改规格已经能提供很多信息。八、如何避免 Agent 变成“自动化幻觉机器”允许它说不知道输出格式中加入unknown、needs_confirmation和assumptions字段。没有证据时拒绝补全比生成一个格式漂亮的错误答案更有价值。把计划和执行分开先让 Agent 输出将要做的文件、命令、影响范围和回滚方式再允许执行。尤其是涉及外部系统时计划本身就是安全检查点。保留中间结果不要只保存最终答案。保留输入清单、结构化中间产物、校验结果和日志失败时才知道是哪一步出了问题。让失败可重试每一步尽量幂等相同输入重复执行不会破坏已有结果。输出使用版本号或临时目录避免半成品覆盖上一版。九、从一个技能开始的六步路线选择一个每周重复、输入相对稳定的任务。写清输入、输出、成功标准和禁止动作。把文件遍历、格式转换和校验写成确定性代码。只把分类、提取、比较和生成交给模型。将 Prompt、代码、权限和验收封装成一个小技能。连续运行一段时间记录失败再决定是否增加 Hook 或自动执行。这条路线的好处是每一步都有退路即使 Agent 部分不稳定代码和 CLI 仍然可以独立使用即使 Hook 暂时关闭技能也能手动触发。十、什么时候不该做 Agent如果任务只需要一次简单转换不必建立完整技能。如果输入经常变化、成功标准说不清、权限边界无法确认也不适合一开始就自动执行。当一个流程仍然依赖大量临时判断时先把它当作人工辅助工具让 AI 生成草稿、给出证据和列出风险由人做最终决定。等规则稳定后再逐步自动化。结论个人 AI 基础设施的自动化顺序应该是先定义 Goal再用 Code 和 CLI 建立确定性基础只有确实需要理解和生成时才引入 Prompt最后把稳定组合封装成 Agent 技能。USER 与 SYSTEM 分离可以保护个人资产Hooks 可以连接生命周期事件最小权限、计划确认、中间产物和可回滚设计则决定了自动化是否值得信任。在工程落地层面模型调用的密钥轮换、成本追踪和接口兼容性也是长期维护的一部分。4SAPI 中转站等聚合接口为这类需求提供了一个统一接入的工程选项是否采用取决于你对运维成本和灵活性的实际考量。PAI 的公开实现已经从早期的 Personal AI Infrastructure 逐步演进到 LifeOS 公开仓库。无论使用哪一种 Agent 工具最重要的原则都不变先写清楚要改变什么、怎样判断成功、哪些动作必须由你确认再让 AI 逐步接管可控的部分。