AI Coding 时代，别动不动就建平台：先把 CLI、AI IDE 和 Skill 用好

假设一个内部工具的需求只有三步：读取配置，调用接口，把结果写进 Markdown。AI IDE 很快做出了可运行版本。接着有人提议加页面，又有人问能不能补账号、权限和操作记录。脚本还没稳定，平台的名字已经起好了。

以前，一个内部工具要不要做，第一道门槛是开发资源。需求排进迭代，前端搭页面，后端写接口，测试补用例，运维准备环境。现在，产品、测试、运营，甚至对代码并不熟悉的人，也可以借助 AI IDE 或命令行 Agent 做出脚本、页面和小工具。

这是好事。

但另一种熟悉的冲动也被放大了：一个脚本刚跑通，就想把它做成服务；两个人开始用，就想补一个管理后台；第三个需求出现，架构图里已经有了“统一平台”“能力中台”“工作台”。登录、权限、菜单、数据库、消息队列、插件市场、运营看板，一样不少。原来的问题可能只需要一个小脚本，最后却养出一套需要长期维护的系统。

AI 降低了写代码的成本，却没有降低系统存在的成本。

代码可以一下午生成，平台要按年维护。依赖会升级，权限要治理，数据要迁移，接口要兼容，告警要处理，用户会提出新需求。AI 能帮忙干活，但这些账不会因此消失。

所以，AI Coding 时代更需要克制。很多个人和小团队真正缺的，不是又一个平台，而是一个统一入口、一套放在仓库里的规则，以及可以反复调用的 Skill。

CLI、AI IDE、AGENTS.md、Skill，再加上必要的 Hook 和测试，已经能覆盖大量真实工作。

先把这套轻量组合用好。平台，应该是问题被反复证明之后的结果，不该成为每个需求的默认起点。

人人都能 Coding，最容易发生的不是创新，而是系统膨胀

AI Coding 带来的变化，不只是程序员写得更快。

需求人员可以生成原型，测试人员可以补回归脚本，运营人员可以处理数据，设计师可以修改前端样式。越来越多原本只能写文档、提工单、等排期的人，开始直接构造解决方案。

这会减少很多等待，也会制造更多“半成品系统”。

过去，开发成本高，团队会被迫先判断：这个需求是否值得做？有没有现成工具？一段脚本能不能解决？现在，生成代码太容易，很多人直接跳过了这些问题。

先生成一个页面。

再加一个账号体系。

再把配置放进数据库。

为了让别的团队使用，补一个开放 API。为了让 API 好管理，再做一个控制台。等到真正的业务价值还没有被验证，维护面已经铺开了。

这不是 AI 的问题，是成本感知发生了偏差。

生成成本下降得很快，理解成本、协作成本和运维成本下降得没那么快。一个人能写出更多代码，不等于团队有能力长期拥有更多系统。恰恰相反，当代码产量上升，命名、职责、权限、测试、版本和废弃规则会变得更重要。

真正危险的不是代码写不出来，而是代码太容易写出来，以至于没人再问：它为什么必须以“平台”的形态存在？

平台这个词，正在替很多不确定性背锅

不少所谓“平台需求”，拆开后并没有平台级问题。

有人说，需要统一入口。统一入口可以是一个根命令。

有人说，需要沉淀经验。经验可以写进版本库里的 Skill。

有人说，需要统一规范。规范可以放进 AGENTS.md、CLAUDE.md 或仓库规则中。

有人说，需要自动校验。格式化、受保护文件、测试和安全检查可以由 Hook 或 CI 执行。

有人说，需要让多个角色协作。任务可以通过 Git、Issue、PR 和 Agent 子任务传递，输入、输出和验收标准都能留下记录。

这些方案当然不一定永远够用。但在需求刚出现、使用人数不多、流程还在频繁变化时，它们往往比一个新平台更合适。

因为此时最重要的不是“统一”，而是看清楚哪些东西真的稳定。

平台会把暂时的做法固化成长期接口。一旦太早做，团队很容易把猜测写进数据库，把临时流程做成菜单，把某一组人的习惯包装成“标准能力”。后来业务变化，平台反而成了最难改的那部分。

页面看起来更正式，未必更接近问题。架构图画得更完整，也不代表需求已经想明白。

CLI 为什么在 AI 时代重新变得重要

很多人对 CLI 的印象还停留在“给资深工程师用的黑窗口”。这个判断已经过时了。

现代 CLI 是一套稳定、可组合、可自动化的文本接口。人可以调用，脚本可以调用，CI 可以调用，AI Agent 也可以调用。同一个动作不必为人、自动化和模型分别实现三遍。

OpenAI 的 Codex CLI 官方文档把终端入口描述为可以检查代码、修改文件、运行命令和自动化重复任务的工作方式；除了交互使用，还可以通过 codex exec 接入脚本与 CI。GitHub CLI 用一个 gh 根命令覆盖仓库、Issue、PR、Release、Actions、API 和扩展。Claude Code 也把命令、Skill、Hook 和子代理放在同一个工作入口里。

这里真正有价值的不是某个产品，而是接口形态。

假设团队需要一套“发布前检查”，最小实现可以是：

repo-tool release-check
  ├─ 检查工作区状态
  ├─ 运行目标测试
  ├─ 扫描配置与密钥风险
  ├─ 生成变更摘要
  └─ 返回明确的退出码

这条命令有三个直接收益。

第一，人能在本地运行，看到失败发生在哪一步。

第二，CI 可以原样调用，不需要再实现一套逻辑。

第三，AI IDE 可以先调用它，再根据失败信息修改代码。规则依然掌握在确定性程序里，模型负责理解、修改和解释，不负责凭感觉宣布“应该没问题”。

这正是 CLI 在 AI Coding 时代的优势：它同时是人的操作面、自动化的协议面，也是 Agent 的工具面。

Unix 在很早以前就提出，小程序应该做好一件事，并预期一个程序的输出会成为另一个程序的输入。Git 后来的 plumbing 与 porcelain 分层，也是类似思路：底层能力保持稳定、可组合，上层再提供更友好的人机入口。

换到今天，CLI 不是平台的低配版。设计得好的 CLI，本身就是最薄、最稳定的一层平台接口。

AI IDE 负责上下文，CLI 负责确定性

CLI 适合执行清晰动作，AI IDE 擅长处理上下文。

打开一个项目后，AI IDE 可以读代码、理解依赖、查找调用关系、修改多个文件、解释失败原因。它离代码现场很近，交互成本也低。需求不清楚时，人可以边聊边收敛；改动范围变大时，模型可以跨文件分析。

但 AI IDE 不应该成为所有规则的唯一存放地。

如果发布检查只存在某段对话里，换一个人、换一个模型、换一个入口，流程就可能丢失。如果团队规范全靠提示词临时提醒，也很容易出现“这次记得，下次忘了”。

更稳的分工是：

• AI IDE 负责理解任务、读取上下文、生成和修改代码；
• CLI 负责执行确定性动作，返回稳定结果；
• 仓库规则负责声明操作范围，例如哪些检查必须运行、哪些目录不能动；
• Skill 负责封装高频、多步骤、需要解释的工作流；
• Hook 和 CI 负责那些不能靠模型自觉的硬约束。

例如，一个缺陷修复流程不必先做“智能研发平台”。它可以由一个 Skill 描述步骤：先复现，补失败用例，做最小修复，运行目标测试，再做缺陷聚焦的代码审查。Skill 调用已有 CLI；CLI 返回真实结果；AI IDE 负责在失败时诊断和继续修改。

这套组合不花哨，但职责很清楚。

模型的概率性留在理解和生成环节，测试、退出码、权限和审计尽量交给确定性工具。哪一步翻车，也更容易定位。

Skill 不是提示词收藏夹，而是可以版本化的工作方法

Skill 经常被误解为“写长一点的 Prompt”。如果只是把几段提示词堆在一个文件里，确实很难产生多大价值。

真正有用的 Skill，至少包含四类东西：

1. 什么时候触发，解决什么问题；
2. 输入、输出和不能越过的限制；
3. 一套可以执行的步骤，以及需要调用的脚本、模板和参考资料；
4. 明确的验收方式，失败后该怎么继续。

OpenAI 的 Skill 文档将它定义为一个目录：核心是 SKILL.md，还可以带脚本、参考资料和资产，并能在桌面端、CLI 和 IDE 扩展之间复用。Anthropic 和 GitHub 的官方文档也采用相似模式：简单、常驻的规则放在项目指令里，只有相关任务才需要加载的详细流程放进 Skill。

这个分层很关键。

AGENTS.md 适合写全项目都必须遵守的短规则，例如测试命令、目录范围和代码风格。Skill 适合写“发布”“故障排查”“写技术文章”“生成测试方案”这类按需触发的流程。脚本处理必须稳定执行的动作。参考资料只在需要时加载，不必每次都把上下文塞满。

这样沉淀的不是一段神秘提示词，而是一套能跟代码一起评审、版本化和回滚的工作方法。

它也比平台更适合早期变化。

流程变了，修改 Markdown 和脚本即可。限制写错了，Git 可以看到差异。某个 Skill 不再适用，可以直接停用。没有数据库迁移，没有前后端联调，也不需要维护一个“Skill 管理中心”来管理三个 Skill。

当 Skill 多到难以发现、权限难以控制、执行记录需要统一审计时，再讨论注册中心和服务化。顺序别反。

一套够用的轻量组合

对个人、项目组和规模不大的团队，一套低成本组合通常可以分成五层。

第一层：仓库就是事实源

代码、配置、规则、Skill、模板和验证脚本都跟着仓库走。

不要把关键流程只放在聊天记录、在线文档或某个人的本地目录里。仓库的重要性来自版本、评审、回滚和责任归属，这些都是长期协作的基础。

第二层：一个根命令收口常用动作

不必一开始追求跨公司的统一 CLI。先在当前项目里收口。

project doctor
project test
project review
project release
project trace

命令命名清楚，帮助信息能看懂，失败时返回非零退出码，机器可读结果用 JSON，给人看的说明走标准输出。现代 CLI 指南把这种接口看作面向人的文本 UI，同时也强调自动化需要稳定的输出、错误流和退出码。

根命令的价值不是显得专业，而是让人、CI 和 Agent 对同一套动作达成一致。

第三层：AI IDE 读取项目上下文

AI IDE 负责理解“这次到底要改什么”。它读取代码和局部规则，调用前面的命令，基于失败结果继续修复。

这里要保留权限边界。默认只给任务真正需要的文件和命令权限；涉及发布、删数据、改生产配置，仍然需要明确授权。AI 能提高操作速度，也会提高错误扩散速度。

第四层：Skill 封装重复流程

当同一套步骤被反复解释两三次，就可以考虑写成 Skill。

注意，是反复出现的步骤，不是把所有知识都塞进一个“万能研发 Skill”。Skill 越大，触发越模糊，维护越困难，最后又会长成一个文本版平台。

一个 Skill 做好一件事，入口明确，产物明确，验收明确。够了。

第五层：用 Hook 和 CI 兜底

模型会忘，规则会漂，人的注意力也不稳定。

格式化、敏感文件保护、依赖检查、单元测试、发布签名，这些能确定判断的事情，不要让模型每次重新推理。Claude Code 的 Hooks 文档给出的典型用途正是编辑后格式化、操作前拦截受保护文件、生命周期事件中执行固定命令。

把需要理解的流程交给 Skill，把必须执行的限制交给程序。

这五层组合起来，已经具备入口、规则、复用、自动化、权限和验收。很多团队急着建设的“平台能力”，其实已经在这里了，只是没有一个大屏和首页。

什么时候 CLI 和 Skill 不够了

克制不等于拒绝平台。

当问题真的跨过规模阈值，平台有它的价值。CNCF 的平台白皮书把平台描述为一组按用户需要呈现的集成能力，目标包括降低认知负荷、减少重复劳动和统一治理。它还特别强调，应优先覆盖多个产品团队最常见的用例，并采用“最薄的合理层”。接口可以是 GUI、API、CLI、IDE 或门户的组合。

所以，判断是否该平台化，不该先问“要不要做个门户”，而应观察下面这些信号。

同一种能力正在被多个团队重复实现

不是需求看起来相似，而是输入、约束、失败模式和验收方式已经足够稳定。多个团队都在维护相近脚本、重复踩同样的坑，统一能力才可能产生净收益。

大量时间耗在跨团队等待和工单上

Evan Bottcher 在 Martin Fowler 网站的文章中，把减少协调和 backlog coupling 视为平台的重要目标。真平台应该让团队自助完成工作，而不是把原来的人工流程搬进新页面，再生成一张新的工单。

安全、合规、权限和成本治理无法靠项目内规则覆盖

当组织需要统一身份、细粒度授权、完整审计、配额、账单分摊和策略执行，单个仓库里的脚本会逐渐吃力。这时，共享服务和集中治理有现实价值。

底层复杂度已经挤占业务开发的认知空间

如果每个团队都必须理解集群、网络、证书、密钥、发布拓扑和观测系统，平台可以提供一条更窄、更安全的“黄金路径”。但黄金路径应该可选、可解释，不能变成只有平台团队才懂的黑盒。

组织愿意长期把平台当产品运营

平台不是一次性交付项目。它需要用户研究、路线规划、支持、稳定性承诺、使用度量和废弃机制。没有长期负责人，只想在季度目标里“把平台建出来”，大概率会得到一个越来越旧的后台。

如果这些信号还不明显，先保持薄。文档、约定、Skill、模板、CLI、IDE 集成、轻量 API，按真实摩擦一点点增加。CNCF 的成熟度模型也明确提醒，更高成熟度会消耗更多资金和人力，达到最高级本身不该成为目标。

真平台不是页面，而是减少等待

“要不要平台化”之所以容易吵起来，是因为大家对平台的理解不一样。

有人把平台理解为门户，有人理解为共享服务，有人理解为组织，有人理解为一组标准。最后讨论半天，争的是名词。

更实用的判断只有三个：

• 使用者能不能自助完成高频任务？
• 团队是否因此减少了重复劳动和跨团队等待？
• 这套能力的长期维护成本，是否低于它节省的成本？

如果答案是肯定的，一套 CLI 加 Skill 也可以承担平台能力。

如果答案是否定的，再漂亮的门户也只是把复杂度换了一个皮肤。

Team Topologies 提出的 Thinnest Viable Platform 很直接：最薄可行平台可以只是一页 Wiki，写清楚允许使用哪些云服务以及怎么使用；如果这样已经够用，就不要再建东西。企业变大、问题变复杂，再逐步加厚。

这句话放在 AI Coding 时代尤其合适。

因为现在最不缺的是“建出来”的能力，最缺的是判断什么值得长期存在。

别把平台当成管理焦虑的止痛片

很多平台并不是被用户需要出来的，而是被管理焦虑推出来的。

工具太多，想做统一入口；流程不一致，想做统一编排；质量不稳定，想做统一门禁；AI 使用不可控，又想做统一 Agent 平台。

这些问题都真实存在。但“统一”只是手段，不是答案。

入口不统一，可能是命名和文档太差；流程不一致，可能是业务本来就不同；质量不稳定，可能是测试和验收缺失；Agent 不可控，可能是权限、日志和工具协议没有设计好。

如果根因没解决，平台只会把混乱集中起来。

更好的顺序是：先找到一条高频用户旅程，把它做短；再把稳定动作提取成 CLI，把重复判断写成 Skill，把硬约束落进 Hook 和 CI。让一小批真实使用者持续使用，观察失败发生在哪里。

等到需求稳定、重复足够多、治理压力真实出现，再把其中需要共享状态和集中控制的部分服务化。

这个过程看起来没有“大平台上线”那么热闹，却更接近工程事实。

AI Coding 的下一阶段，是少造系统，多交付结果

人人都可以 Coding，不代表人人都应该建平台。

AI 把编码能力扩散出去之后，稀缺的东西已经变了。以前稀缺的是实现，现在稀缺的是问题定义、范围判断、验收设计，以及对长期维护成本的耐心。

一个能工作的脚本，先放进仓库。

一组反复出现的命令，收口成 CLI。

一套反复解释的步骤，沉淀成 Skill。

必须每次执行的规则，交给 Hook 和 CI。

跨团队的重复、等待、治理和认知负荷真的出现，再建设共享服务；只有当 GUI 能明显降低使用门槛时，再做门户。

这种顺序，是在把新增代码连同未来的维护成本一起管理。

平台当然不会消失。真正值得留下的平台，会从一条被反复验证的用户旅程里长出来，而不是从“公司也该有个平台”的念头里长出来。

AI 可以把系统生成得越来越快。少维护一个没人真正需要的平台，也是一种交付。

#AI 编程 #AICoding #CLI #AgentSkill #平台工程 #研发效能