从CLI原理出发，如何做好AI Coding

话题背景：随着LLM的能力提升，从早些AI产品能快速帮助用户制作prototype，到现在当前市面上不断涌现出新的AI Coding工具，这些AI Coding背后的工具原理是什么？我们在选择这些AI Coding工具的时候，需要关注哪些信息，了解背后的原理，才能更好地使用这些工具。

Q：回想一下，你接触过哪些AI Coding工具？当前使用过程中有哪些问题？

当我第一次接触到Claude code的时候，很惊讶发现他是一个命令行工具，他不是一个IDE，甚至都不是一个插件，当时在想，是时代在倒退么？为什么还会有AI产品是一个命令行工具，像是回到了linux时代。随着使用越来越深入，逐渐发现了他的魅力。

在人工智能编程工具的浪潮中，CLI工具的崛起并非偶然。它的成功不仅在于强大的代码生成能力，更深层次的原因在于其背后遵循了一套历久弥新的设计哲学——与经典的Unix哲学不谋而合。

在Unix系统中，一切皆文件（Everything is a file） 是一种核心设计哲学，指的是系统中的所有资源，无论是设备、管道、目录、普通文件还是套接字等，都被统一视为文件。这种设计使得操作系统能够提供统一的接口来访问这些资源，极大地简化了编程和系统管理的工作。在Unix系统图形化界面出现之前，访问这些文件（资源）的唯一方式就是终端。

iFlow CLI也遵循这种设计美学。通过终端，iFlow CLI几乎可以像程序员一样访问用户电脑上的几乎所有资源。所有文件均可通过命令行触达，包括代码文件。iFlow CLI内置了丰富的工具，比如文件搜索、读写文件操作、运行脚本命令等。它就像一个熟悉命令行的资深开发者，通过在终端执行脚本命令，几乎可以完成所有终端操作，访问所有系统资源。

一切都奔着实用主义

和Unix上的其他命令行工具一样，CLI非常小巧轻量，这也是其核心设计哲学。它不像web应用那样需要复杂的界面设计，无需考虑按钮位置和样式布局。对于命令行工具，唯一需要考虑的就是用户在输入框中输入的内容，然后静待AI完成输出。一切就是这么简单。

CLI的灵活之处还在于其可组合性，这也体现了Unix的组合型原则——程序应该能协同工作，一个程序的输出应成为另一个程序的输入。在终端命令行中，通过Linux的管道命令，可以很轻松地将一个命令的输出作为CLI的输入，然后让CLI接手处理后续任务。他也可以很方便被其他应用程序，以子进程的形式调用。

同时，CLI也提供了Agent SDK，可以被集成到业务系统中，让业务系统快速具备AI的能力。

灵活、轻量是CLI的特点，他是一个非常通用的Agent内核，它以极简的方式启动，却具备很高的上限。

他不光只是用于代码编写，还可以用于其他AI作业。
CLI预制了一些通用能力，使其能够处理各种常见工作。比如todo-list功能，让CLI像人类一样，将要做的事情一条条写到便笺纸上，从而跟踪任务执行情况而不遗忘。同时，它也预留了丰富的扩展接口，允许技术人员根据真实环境进行扩展和自定义。因此，在CLI中，可以看到hooks、commands、sub agents、output styles等扩展功能。通过扩展这些智能体，可以让CLI做更多事情，远不止编程。
比如： 

• 用Claude code管理知识库
• 用Claude Code管理自动化生活
• Claude code 生活操作系统
• 使用iFlow CLI当作桌面助理，整理文件等

更多案例：心流开放平台[1]

下述以iflow cli为例，讲述iflow cli的技术原理

CLI为代表的Agent架构，是Anthropic的Building Effective Agents [2]& Building Multi-Agent Research System[3]的典型实践。

他是一个通用的agent系统，有一个Control Loop，一个Chat Messages，叠加Memory + Tools，通过不断调用外部工具的方式，形成loop。虽然在iflow cli、claude code中引入了sub agent，但严格意义上它不是一个Multi-Agent系统，SubAgent只是一种特殊的tool，无agent handoff，无agent通信机制。

在这种single agent中，将能力提升到极致，上下文工程起到关键作用。

我在文章Context Engineering在Coding和DeepResearch上的方法和案例这篇文章中，有分享5种上下文工程的方法，在cli上均有体现，分别是：

正是这种极致的上下文工程，使得single agent能保持简单灵活的同时，并保持高效。

那么为什么不做multi-agent？

构建Multi Agent系统的挑战在于：在subagents之间通讯是一件非常困难的事情。比如在Coding场景，用一个Sub agent写测试或者做其他不同的事情，你需要怎么精确跟sub agent解释所在的代码，以及将测试结果告知到main agent的上下文。

其次，multi-agent的pipeline，往往是比较固定，有具体的agent，有具体的流程，往往丧失了一定的灵活性。

因此，采用single agent的内核，他更简单、灵活，这也是为什么他不止于coding这一个场景。事实也证实，像claude code这一类的cli工具，也逐渐从coding往其他领域延伸。

有很多话题讨论，在AI越来越强的时代，未来AI会不会取代技术人员。在 生产环境中氛围编程，软件工程师的价值在哪里?有个观点，技术人员依然会有很多不可取代性，比如人性的责任感，人需要为生产环境负责。其次，在一些专业领域，人的创造性、架构设计经验，这些是AI取代不了的。AI会取代我们coding的工作，但是不会取代技术人员。

在美国一些创业公司，越来越多的技术人员走向前台，他们和客户打交道，理解用户需求，然后转化成产品，最后交给AI来实现。未来的生产关系会发生一定的变化，产品和技术的边界可能没有那么清晰，而工程和算法的边界也许也不会那么明显。谁懂用户，谁懂产品，才能有更好的发展。

组织能力才是AI公司真正的壁垒[5]这篇文章里面提了几个观点：

• 搭配SOP，Claude Code可以提升很大的效率；
• 人是AI的Context Provider；
• AI Native的组织：每个人都是为最终结果负责的 Builder；

因此，当下，我们需要更快学会如何使用AI，“奴役”AI为我们coding。

正确认识AI

将AI视为强大的工具，而非万能的同事。它擅长生成文本和代码，但缺乏真正的理解和判断力。因此很重要一点，请容忍他犯错，你需要去纠正他。

其次，在coding场景，选择一个好的指令遵循的模型很重要。需要看一些coding能力，一些排行榜会比较有用。比如，在iflow cli中，我们评测下来，glm4.6的评测分数相对比较高。另外，我们也发现海外coding工具，在国产模型下表现并不好。

学习有效的Prompt(或者Context) Engineering

与AI交流需要技巧。提供详细、清晰的任务描述，包括背景、目标、约束和示例。例如，不要简单地说"做一个电商APP"，而应该说明具体的需求、场景、scope。

在AI Coding相关经验分享这篇文章中，有谈到一些prompt技巧，我比较喜欢的是CO-STAR法则。 另外，文章中也分享了一些context engineering技巧，比如提供精确的信息、有效压缩、控制任务粒度、使用外部文件等。

车子开的好不好，车手很关键（先PUA自己 ^_^）

理解AI的局限性

AI助手生成的是模式，而非真正的理解。当任务超出其训练范围或需要深度领域知识时，合理划分AI任务边界非常重要，我们要判断什么时候进行干预，什么时候可以完全委托，什么时候需要半委托。
在尝试修改生产级别的代码时，我一般会根据任务复杂度和自身能力范围合理分配 AI 的工作，按照我自己的能力范围划分为3个类别：

1.能力范围内的任务：实现逻辑是清晰的，实现需要花很多时间让 AI 处理逻辑清晰但实现耗时的任务，可以显著提升效率。我把这类任务称为"搬砖提效"，常见的如CRUD，稍微复杂一点的像需求文档是非常清晰的，技术设计完善，性能、稳定性等方案也已经完善，剩下就是coding实现。

2.略超出能力范围的任务：如果我通过调研、短期学习，就可以解决的，那我也会把这部分任务交给AI去解决。，比如我在一个项目环境里面需要调用阿里云 SDK ，他并没有提供javascript版本的签名，我需要详细文档阅读、参考python源码，改成js的版本。这种任务交给AI实现会非常方便，一方面他有能力去fetch官方的文档阅读，另外，对于一些流行的模型，比如Claude，他已经把主流的官方文档都已经训练过了，甚至不用阅读，就可以凭借内生的知识就可以帮我们补全。

3.远超能力范围的任务：对于自己完全不熟悉的技术领域，不建议完全依赖 AI，除非这个代码仅仅只是用于demo用途。有个翻车例子是，我对React Native了解甚少，有个非常紧急的项目，期望用Claude Code生成一个React Native项目。AI前期代码写的很快，基本上半天就有一个可以跑在手机上的demo出来了。但是到了项目后期，想要加更多效果，就显得非常困难了。代码量越来越多，冗余代码问题、设计问题都藏在底下不得而知，效率变低，成本变高。最后还是回到使用熟悉的语言。

探索多智能体协作

尝试让多个AI Agent协同工作，例如一个负责设计，一个负责实现，一个负责测试，可以产生更全面的结果。

可以使用git worktree同时运行多个cli实例处理不同任务。git worktree是多检出的轻量替代方案，允许将同一仓库的多个分支检出到不同目录，每个worktree有独立的工作目录和文件，但共享历史和reflog。比如一个负责前端，一个负责后端； 又或者，一个负责代码实现，一个负责测试。

另外，尝试使用Spec（在心流开放平台，我们称之为workflow），他是一种将经验沉淀成sop，通过command、sub agent等智能体扩展实现的一种方式。

AI-Dev-Task

我见过最简单的研发spec: AI-DEV-TASKS[6]

他将研发工作分解为3个步骤：

一、需求澄清

二、任务拆解

三、执行任务

每个任务人确认没问题后，再继续下一步。

R2C

将需求文档之间转成代码。

BMad Method

复杂的Spec：Bmad method[7]，他的agile工作流定义了7种agent，分别是：产品经理、分析师、UI/UX专家、scrum master、开发、测试、架构师，然后通过文件按需加载的方式实现agent的人格、技能、知识库的切换（很好地诠释了出来混身份是自己给的）。通过严格执行agile软件研发流程，从而达到高质量代码生成的目的。

Github Spec Kit

为什么需要 Spec Kit？

如果你曾经历过以下情况，那么 Spec Kit 正是为你而生：

• 需求变化无常：客户说要一个"简单的登录功能"，结果做到一半发现需要支持第三方登录、忘记密码、双因子认证......

• 代码越写越乱：开始时想法很清晰，写着写着就偏离了原始目标，最后自己都不知道在做什么；

• 团队理解不一致：每个人对同一个需求的理解都不同，导致代码风格和实现方式千差万别；

• AI 生成的代码不可控：让 AI 写代码很快，但经常生成的代码不符合预期，需要反复修改；

这些问题的根源在于一个核心问题：意图偏移。也就是说，从最初的想法到最终的代码之间，意图在传递过程中逐渐偏离了原始方向。

介绍文档[8]

更多Spec(workflow)，可以在心流开放平台找到。

接受风格差异

AI生成的代码风格可能与你习惯的不同。这种差异不一定意味着好坏，而是提供了不同的视角。你需要更多关注在代码的质量上，包括架构是否一致、需求是否对齐、逻辑是否正确等。

持续实践

从简单任务开始，初次使用AI时，从简单、明确的任务开始，如编写单元测试、实现已定义好的接口等。然后频繁使用AI助手是提高协作效率的关键。

让AI参与的代码编写，可以包括BI分析（SQL编写）、Java模块（业务逻辑）、算法模块等。也可以让他操作一些excel、word文档，使用常用的python库进行一些ocr、数据处理、格式转化等。

随着时间推移，你将学会什么时候依赖AI，什么时候自己解决问题。

促进AI与团队对齐

通过提供代码风格指南、架构文档和团队约定，帮助AI生成更符合团队期望的代码。让AI生成文档，保持文档自动更新，在生成代码的时候能方便快捷检索到文档，这个非常重要。devin的deepwiki可以帮助做到这件事。iflow cli社区也有人贡献了deepwiki-rs，他可以自动分析代码，然后将代码逻辑生成AI友好的文档。后续AI生成新的代码，也可以自动更新文档。

其次，建立团队内部的AI使用指南，明确在哪些场景下使用AI，如何审查AI生成的代码等。AI生成的代码速度远高于人，对AI提交到git的代码质量门控显得尤为重要。我们需要重新重视单元测试、集成测试、code review等这些环节。可以借助github、aone的workflow建立一些自动化的流程，提升review 的效率。不过，人在这里还是非常重要，对于生产的代码，依然需要做到每一行都要review。

建立优化闭环

允许AI犯错误，记录AI表现良好和不佳的案例，在AI犯错误之后，我们可以更清楚了解AI能力的边界，通过不断改进你的提示和工作流程，建立良好的人机协作闭环，从而降低AI后续犯错误的概率，提升代码的质量，从而逐渐让人参与的部分变少，让agent帮你做反馈和改进，让AI自闭环。

使用Agent对抗机制，能显著提升代码质量。比如写完代码之后，加入测试流程（也可以是sub agent)。

最好的工具不是替代开发者，而是增强开发者的能力，成为他们思想的延伸。AI不会取代技术人员，而不会用AI的技术人员迟早会被取代。