Marico's space
我关注代理式编程（Agentic Coding）的原因，和我关注工程流程的原因一样：任务一旦变得复杂，我希望工作能以可检查、可重复、可持续的方式推进下去。
现在的AI辅助编程，大多数时候还是一种即兴表演。问一下，给个结果，调一下提示词，再试一次，然后祈祷有用的推理过程还藏在聊天记录里。小的改动这样做还行。但一旦任务涉及到架构、测试、评审或者合并请求（PR），这套玩法的说服力就大打折扣了。
我真正想要的是这样的工作流：模型能帮我思考和执行，但整个过程是在一个我可以事后检查的结构里进行的。我想要产出物（artifact）、关卡（gate）、以及明天能继续工作的能力——而不是要从记忆里重建整个上下文。
这就是我使用 po8rewq/agentic-skills 的原因。
它提供了一种将代理式编程工程化的实用方法，而不是把一长串聊天回合串起来。任务会依次经过需求、架构、实现、检查、评审、创建合并请求这几个阶段。每个阶段都会留下我可以阅读、验证、甚至质疑的东西。
有意思的地方不只是有个命令行接口（CLI）。很多工具都有CLI。
真正重要的是，它把AI辅助编程变成了一套分阶段系统：
这让工作的感觉完全不同了。我不再问"下一步应该提示什么"，而是问"这个任务处于哪个阶段，在继续之前应该有什么"。
真正让我想通的是：我发现自己花在脑子里保持上下文上的精力变少了，花在评估实际产出上的精力变多了。
仓库本身相当精简，而且这种精简是我喜欢的风格：
agentic/ 包含Python包和CLI入口pipelines/ 包含流水线定义，比如 default.yaml、cheap.yaml 和 production.yamlskills/ 包含每个阶段使用的Markdown指令templates/ 和 scripts/ 包含设置辅助脚本我喜欢这种设计：共享仓库保持集中，而每个项目只保留项目特定的部分。
在目标仓库里，我通常只需要：
agentic.yaml.ai/skills/.ai/context/.ai/memory/这种分离是工作流能持续运行的原因之一。编排逻辑放在一个地方，每个仓库保留自己的命令、上下文和运行规则。
让我意外的是，这么小的分离就能极大地改变系统的感觉。它不再像一个精巧的演示，而是像一个我能一直用下去的东西。
配置文件不仅仅是设置。它是告诉流水线如何运作的核心部分：用哪个provider、运行哪些命令、什么时候需要审批、加载什么上下文、以及任务如何从一个阶段推进到下一个阶段。
一个很小的 agentic.yaml 就能说明这个思路：
project: name: my-api default_branch: main
providers: default: claude-code available: claude-code: {command: claude}
forge: provider: github create_pr: true
commands: install: pnpm install lint: pnpm lint typecheck: pnpm typecheck test: pnpm test build: pnpm build
这显然不是一个完整的生产配置，但它已经能让模型在一个真实的工程边界内运作了。它知道调用哪个provider、哪些仓库命令算作检查、主分支是什么、以及最后是否要准备一个合并请求。
在此基础上，我通常会添加那些让工作流更严肃的部分：
一旦这个文件存在了，我就开始用流水线行为的思路来思考，而不是孤立的提示词。
我没想到的是，一个看起来很无聊的配置文件能起到这么大的作用。它悄悄地把"在这里用AI助手"变成了一种有边界的运作模式。
设置过程刻意做得很简单，这本身就是它吸引人的地方。
我从 po8rewq/agentic-skills 安装共享包：
cd /path/to/agentic-skills
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install --upgrade pip setuptools
python3 -m pip install -e .
这给了我三个命令：
run-pipeline
validate-agentic-config
install-agentic-skills
在目标项目里，我复制示例配置：
cp /path/to/agentic-skills/agentic.example.yaml /path/to/project/agentic.yaml
然后安装共享的skills：
install-agentic-skills --source /path/to/agentic-skills/skills .ai/skills
对于初始的仓库上下文和记忆文件：
install-agentic-skills --with-context --with-memory .ai/skills
到了这里，工作流就准备好在真实任务上试试了。
理解这个工作流的最好方式，是用它跑一个很小的改动。
拿一个小型但真实的任务来说："给接口X添加审计日志"。
在我用这种方式工作之前，这类任务通常会变成一串松散的提示词和手动检查。我会解释接口、请求一个计划、请求实现、想起来要思考日志格式、怀疑自己是不是漏掉了迁移或配置更新、手动运行测试、然后在打开合并请求之前再做一次单独的清理。
有了流水线，同样的任务变得更有结构：
| 之前 | 用流水线之后 |
|---|---|
| 在聊天里描述任务，不断调整提示词。 | 用任务启动，让流水线创建显式需求。 |
| 架构上的考虑只存在于脑子里，除非我停下来写下来。 | 架构是一个阶段，所以受影响的模块、风险和计划中的文件在早期就被记录下来。 |
| 实现可能会偏离，因为提示词一直在变。 | 实现是根据需求和设计产出物进行的。 |
| 检查很容易被推迟或做得不一致。 | Lint、类型检查、测试和构建是流程的一部分。 |
| 评审通常发生在代码已经感觉"完成"之后的非正式环节。 | 评审是一等公民阶段，有产出物和后续修复。 |
| 如果被打断了，我得从聊天历史和git diff里重建上下文。 | 可以从 .ai/runs/ 下的保存的运行产出物恢复。 |
这是我最在乎的实际差异。流水线不只是帮我更快地写代码。它让任务在推进的过程中保持清晰可读。
对于"给接口X添加审计日志"这样的任务，通常意味着每个阶段都会给我具体的东西：
这是让我感到踏实的地方。即使是小型任务，工作流也留下了足够的结构，让我能检查推理过程，而不只是信任最终的diff。
我通常先用干跑（dry run）试一下：
run-pipeline --dry-run --skip-approval --task "Preview the workflow"
这让我快速了解配置、阶段顺序和提示词，而不用实际执行工作。
然后我会尝试一个故意很小的任务：
run-pipeline --pipeline cheap --task "Fix a typo in the README"
我喜欢先用简单的任务，因为它能教我工作流的运作方式，而不用同时调试复杂的变更和新流程。
每次运行都保存在 .ai/runs/<时间戳>-<任务名>/ 下。这个目录是我喜欢这个方案的最大原因之一。它保留了合并后的配置快照、提示词、provider输出、命令结果、状态和合并请求上下文。
如果运行中途停止了，我可以恢复它：
run-pipeline --resume .ai/runs/2026-07-07-add-audit-logging
这听起来是个小细节，但实际上极大地改变了体验。中断不再是破坏性的。
这是另一个让我想通的时刻。可恢复听起来像是一个便利功能，直到你在一个充斥着会议、打断和半成品想法的真实工作周里用到它。
默认的流水线是刻意设计成线性的：
这种线性不是限制。它赋予了工作流形状。
更重要的是，每个阶段留下的输出类型不同：
后续阶段只有在前面阶段状态足够好的时候才会执行。这就是让流水线对我来说感觉真实的原因。它不只是一串标签。它是一系列具体的产出物。
这是让我觉得有说服力的地方。对于真实的软件任务，我不需要每次都发明新的流程来使用AI。
当我想让一个任务具有以下特点时，我会采用这种代理式编程：
当一个变更在实现之前需要需求评审，或者当我想让评审和创建合并请求发生在同一个流程里而不是作为分离的手动清理步骤时，它特别有用。
实际上，我觉得这最适合用于个人开发者或小团队做后端、基础设施、平台或全栈工作时，因为这类任务会同时涉及多个关注点：代码、测试、配置和评审。对于快速编辑或高度视觉化的探索性工作，它的开销远大于收益，就没那么吸引人了。
这个工作流不是免费的。
对于trivial的任务，开销可能大于价值。它还需要纪律：如果配置、skills或仓库上下文偏离了现实，流水线很快就会变得不那么有用。
调试流水线行为本身也可能是一项工作。当一个阶段产出质量不高时，问题可能是提示词、配置、上下文文件、模型选择或者任务本身。这是一个比随机提示词迭代更有结构的问题，但它仍然是一个你需要维护的系统。
它也不太适合高度探索性的工作。如果我还在搞清楚自己到底想做什么，分阶段流水线可能显得有些为时过早。我发现它最有用的时机是：任务已经足够真实，可以从显式需求、检查和评审中获益。
我学到的最主要的东西是：当代理式编程不再感觉像魔法的时候，它才变得更有用。
我不想要一个有时候能写代码、有时候会跑偏的不透明助手。我想要一个能帮助执行的系统，同时留下足够的结构，让我能理解发生了什么、质疑它、然后继续推进。
这是对我来说最重要的转变。我不再用提示词来思考，而是用阶段、产出物和决策来思考。