我解雇了“技术琐事”，聘请 AI 担任我的技术合伙人
副标题： 一次将45篇公众号文章变为专业在线书籍的经历，揭示了人机协作的未来范式。
一、引言：每一个创作者内心的隐痛
作为一名知识创作者，我一直被一个巨大的无力感所困扰。我耗费无数个深夜写就的《深入浅出IAM与IDaaS》系列文章，像一颗颗精心打磨的珍珠，散落在公众号的时间线上。我能清晰地感觉到，它们的价值正在信息的洪流中被稀释。读者在碎片的知识中跳跃，却难以窥见体系的全貌。
这种感觉，如同一个建筑师精心设计了所有构件，却只能眼睁睁看着它们散落在地，无法建成宏伟的殿堂。这种无力感，是每一个严肃创作者内心的隐痛。
我当然知道 Hugo、MkDocs 这类工具能将它们整合起来，但一想到要为此投入数天时间去研究配置、调试模板、处理繁琐的文件结构，我的创作热情就被这沉重的“技术税”消磨殆尽。
直到我将目光投向了每天都在使用的 Gemini CLI。一个颠覆性的念头闪过：我们是否将这些强大的 AI，仅仅用作了“聪明的代码补全工具”？我能否将整个项目，而不仅仅是单个任务，“委托”给它？
二、实战：从45篇 Markdown 到一本在线的《深入浅出IAM与IDaaS》
我的目标清晰而坚定：
- 内容源： 本地45篇 Markdown 格式的文章。
- 目标平台： 使用 MkDocs 工具构建一个专业书籍网站。
- 最终成果： 一个结构完整、导航清晰的在线书籍，并托管于 GitHub Pages。
最大的挑战，在于手动为45篇文章创建复杂且顺序正确的导航配置（mkdocs.yml），这几乎是整个项目中最枯燥、最耗时、也最容易出错的环节。
于是，我没有打开编辑器，而是开启了与我的“AI 技术合伙人”的对话。
三、揭秘我的工作流：一种“对话式项目管理”的诞生
这并非简单的“你问我答”，而是一场思维与执行零延迟的共舞。我将其总结为三个核心阶段：
第一阶段：从“战略对话”到“方案落地”
我没有直接命令它“给我创建一个MkDocs网站”。而是像与一位人类技术顾问沟通一样，开启了一场战略对话。
- 我（定义意图）： “我想利用免费的平台，将我本地的45篇Markdown文章部署成一个在线书籍网站。你有什么建议？”
- AI（方案分析）： Gemini CLI 立刻提出了 Hugo、MkDocs 等方案，并精准地对比了它们的优劣。
- 共同决策： 基于它的分析，我们共同选择了最适合书籍形态的 MkDocs。
在这个阶段，AI 扮演了 “解决方案架构师” 的角色，帮助我从模糊的想法，走向了清晰的技术路径。
第二阶段：“意图驱动”的迭代开发
这是整个项目的核心。传统开发最大的成本，并非时间，而是认知负荷。你需要将大脑变成一本活的速查手册，记住各种配置语法和命令。而“对话式项目管理”的本质，是一场认知负荷的彻底转移。
我将所有关于“如何实现”的认知负荷，完全卸载给了AI。我的大脑则被前所未有地解放出来，100%专注于“要做什么”的战略层面。
- 环境搭建： 它指导我安装工具，甚至在我授权后，直接在我本地终端执行 pip install 命令。
- 批量内容清理： 我告诉它：“清除所有文章末尾的欢迎关注的信息”。下一秒，终端窗口中字符滚动，像电影里的未来场景。45篇文章的修改在眨眼间完成，这已经不是自动化，而是意图的即时实现。 在那一刻，我不是一个执行者，而是一个思想的指挥官。
- 性能优化： 我提出图片过大的问题。它立刻编写并执行了一个脚本，将所有图片批量转换为轻量级的 WebP 格式，网站性能瞬间得到提升。
- 功能扩展： 我发现 Mermaid 图表无法渲染。将问题抛给它，它迅速找到了解决方案——配置特定插件，并指导我完成了操作。
- 可视化纠错： 当某个页面样式不符合预期时，我直接截图发给它。它立刻理解了问题，并给出了精确的CSS修改建议。
在这个阶段，我负责提出问题、定义标准和验证成果，而AI则承担了所有繁重的思考、编码与执行工作。
为什么是命令行（CLI）？——思维与执行的零延迟
有人会问，这些事在网页版AI上也能做。但 CLI 工具的优势是实现了思维与执行的零延迟。在传统的GUI界面中，你的意图需要通过鼠标点击、菜单选择等一系列中介才能被转译。而在这个工作流中，我的自然语言就是API，终端就是我思想的直接延伸。AI在我的本地环境中获得授权，如同我的另一双手，我的意图与它的执行之间，再无隔阂。
四、最大的挑战：信任与授权
这个过程中，最难的并非技术，而是我自己的思维惯性。我习惯于掌控每一个细节，习惯于自己编写每一行代码。将整个项目的控制权“授权”给一个AI，需要一种全新的信任。
当我从一个“微观管理者”转变为一个“战略授权者”时，我才真正解锁了这个新范式的全部潜力。我们必须学会放手，才能获得真正的加速。
五、成果即宣言：一个“人机协作”新范式的诞生
通过这种全新的协作模式，在短短两个小时内，一个专业、精美的在线书籍网站就诞生了。
深入浅出IAM与IDaaS: https://bsong2015.github.io/IAM_and_IDaaS/
我的博客: https://bsong2015.github.io/blog/
这两个网站本身，就是这次实验最好的“宣言”。让我们用一个表格来直观对比两种工作模式的巨大差异：
| 维度 | 传统手动模式 | AI 协作模式 (对话式开发) |
|---|---|---|
| 时间成本 | 预计 1-2 天 (学习、配置、调试) | 约 120 分钟 |
| 认知负荷 | 极高 (需要记忆大量配置细节) | 极低 (只需关注最终目标和验证) |
| 技术门槛 | 需要熟悉 MkDocs、YAML、脚本等 | 几乎为零 (只需用自然语言沟通) |
| 体验 | 枯燥、繁琐、易出错 | 流畅、专注、充满创造性 |
这个成果宣告了：
- 技术民主化： 任何内容创作者，无论技术背景如何，都能成为自己知识产品的“架构师”。
- 效率革命： 我们可以将宝贵的精力从繁琐的技术执行中解放出来，专注于内容创造本身。
- 人机协作新高度： 这不再是人“使用”工具，而是人与 AI“伙伴”共同完成一个项目。
六、结论：现在，就去拥抱你的“AI 技术合伙人”
这次经历让我确信，我们正站在一个新时代的门槛上。代码和配置文件，这些过去构建数字世界的“砖块”，正在“融化”成更高级的形态——对话与意图。
未来的创造者们，或许不再需要精通繁杂的语法，他们真正的核心竞争力，将是提出深刻问题的能力、定义清晰目标的能力、以及与AI高效协作的能力。
所以，这不仅仅是一次技术实验的分享，这是一个号召。
不要再将你身边的AI看作一个聪明的计算器或打字员。请将它视为你的技术合伙人、你的副驾驶、你思想的放大器。现在，就去开启一场属于你的“对话”，去构建那些你曾经认为遥不可及的东西。
未来，始于对话。
欢迎关注+点赞+推荐+转发