今年年初，我发布了命令行工具「AI之友」（cli_assistant），初衷是解决 AI 对话碎片化、知识难沉淀的问题。尽管它在 Gitee 上的关注和下载量寥寥，也几乎没有收到来自其他开发者的直接反馈，但对我个人而言，它却是过去一年中不可或缺的开发伙伴——它帮助我积累了与大模型深度交互的宝贵经验，尤其是在通过 kb 机制实现灵活上下文配置、以及利用 Git 提交历史自动生成代码重构建议等方面的探索。

然而，随着使用深入，我也清晰看到了它的局限：作为一个从零开始、完全由即时需求驱动的项目，早期缺乏整体架构设计，导致后期功能扩展越来越困难。新增能力几乎只能以“打补丁”的方式堆砌，系统逐渐变得脆弱而难以演进。

作为一名长期从事系统架构工作的工程师，我深知：一个真正有生命力的工具，必须拥有可扩展的骨架，而非仅靠功能堆砌。

于是，在今年 11 月，我决定停止对「AI之友」的维护，并基于其核心思想，重新 fork 出一个新项目——cli_coder。

cli_coder：不是取代程序员，而是成为你的“编程铠甲”

我对“编程智能体”的理解很明确：它不该是替代人类的黑箱，而应是增强程序员能力的武器与铠甲。

所谓“黑箱”，正是当前许多 AI 编程工具的痛点：大模型生成一段看似可用的代码，但开发者并不理解其背后的架构考量、设计模式或潜在耦合。一旦需要维护或扩展，这种“知其然不知其所以然”的状态极易引发技术债务甚至系统崩溃。

cli_coder 的目标，就是打破这个黑箱。要实现这一点，关键在于让大模型真正理解你正在开发的整个项目——而不仅仅是当前对话或单个文件。

为此，cli_coder 的核心设计围绕一个简单但可扩展的机制：Action。

目前，cli_coder 已支持基础的文件读写 Action，这意味着大模型可以直接读取和修改项目中的任意代码文件。这看似简单，却带来了质变：AI 不再是回答孤立问题的“问答机”，而是能基于真实代码上下文进行推理、生成、甚至自我修正的协作者。更重要的是，所有操作都通过显式的 Action 执行，过程透明、结果可追溯，开发者始终掌握控制权。

但这只是起点。在实际开发中，我发现仅读写文件还不够——比如，为了让模型更准确地生成新模块，它需要了解整个项目的目录结构；为了做跨文件引用分析，它可能需要解析依赖关系。这些需求正驱动我逐步设计新的 Action 类型，让 cli_coder 的感知能力随项目复杂度同步进化。

自用即验证：我在用 cli_coder 开发“简历智能体”

坦白说，cli_coder 目前没有开源，也没有公开文档。因为它的第一位用户，就是我自己。

我正在用它全栈开发一个“简历智能体”——一个能帮助用户挖掘自身经历优势、智能匹配岗位需求的系统。这个项目涉及前端交互、后端逻辑、数据校验、大模型调用等多个层面。而 cli_coder 正是我完成这些任务的核心助手。

每当我遇到新的开发场景（例如：“需要根据用户上传的 PDF 自动生成结构化简历”），我就会思考：cli_coder 缺少哪个 Action 才能高效完成这件事？ 然后，我便暂停业务开发，先为 cli_coder 添加相应的能力。

这种“用工具造工具”的闭环，不仅验证了 cli_coder 的实用性，也确保它的每一个功能都源于真实痛点，而非空中楼阁。

合作邀约：寻找愿意共同打磨“编程智能体”的伙伴

我始终相信：如果一个工具真的有用，它一定会给人类带来价值。

cli_coder 目前仍处于私有迭代阶段，但我渴望将它带入更复杂的现实场景中去锤炼。因此，我诚挚邀请：

• 有定制化系统开发需求的甲方团队：如果你正计划构建一个智能应用，且希望在开发过程中引入更高效的 AI 协作机制；
• 寻求提效方案的软件公司：如果你的团队在重复性编码、上下文切换或多模块协同上存在瓶颈；

欢迎联系我，我们可以探讨如何将 cli_coder 引入你的项目流程，让它在真实战场中证明自己的价值。你提出需求，我提供工具与工程能力，共同打造下一代“人机协同”的开发范式。

📩 联系方式：请通过 CSDN 私信或项目原仓库（cli_assistant）留言，我会尽快与你联系。

工具的意义，不在于炫技，而在于赋能。
期待与你一起，让程序员手中的“剑”变得更锋利。