155 lines
17 KiB
Markdown
155 lines
17 KiB
Markdown
---
|
||
layout: post
|
||
title: "慢才是快"
|
||
subtitle: "一份写给智能体工程师的开发宣言"
|
||
date: 2025-09-02 16:50:00
|
||
author: "Wantsong"
|
||
keywords: "智能体开发, AI工程, LLM应用开发, 确定性工程, 不确定性工程, CCPE, 提示词工程, RAG, 多智能体, AI开发原则, 大模型应用"
|
||
description: "当资深的Java工程团队首次涉足不确定性的智能体开发时，会遭遇怎样的思想阵痛？本文是一份写给所有从确定性软件工程转型AI开发的工程师的开发宣言。作者通过一个真实的客户项目，深刻反思并总结出六大核心原则：“混合工程”、“绿野仙踪协议”、相信实测而非“超长上下文神话”等。文章进一步提出了CCPE（智核提示工程）框架，旨在将智能体开发从“炼金术”拉回严谨的“系统工程”轨道。如果你正面临相似的挑战，这篇文章将为你提供一套经过实战检验的思维模型与行动指南。"
|
||
params:
|
||
published: true
|
||
tags: ["Original","Thinkpiece","FieldNotes","PublicIntellectual","CognitiveScience","LearningSystems"]
|
||
image: "https://imgs.wantsong.life/bk8FtREAuY.jpg"
|
||
categories:
|
||
- "THINKING"
|
||
- "SocialTech"
|
||
---
|
||
|
||
## 引言：一个会议纪要智能体引发的“思想阵痛”
|
||
|
||
故事始于一次内部的成功。我们基于CCPE框架，为团队打造了一个会议纪要智能体。它像一位勤勉的产品经理助理，安静地“旁听”我们的会议，然后生成一份结构清晰、重点突出的纪要。效果拔群。很快，一位客户在与我们开会时，亲眼见证了它的能力，并立刻提出了合作意向。
|
||
|
||
团队的兴奋是显而易见的。我们都是经验丰富的Java工程师，习惯了将需求转化为精确、可靠的代码。然而，当我们将熟悉的工程思维直接套用在这个客户项目上时，一种深刻的“惯性失灵”发生了。
|
||
|
||
我看到了三面镜子，照出了我们的困惑：
|
||
|
||
1. **没有抓重心：** 产品框架一上来就包含了登录、用户管理、权限控制……这些我们闭着眼睛都能实现的功能被放在了首位。但项目的真正核心——那个不确定的“智能”，那个能让客户买单的“纪要整理能力”，却被淹没在了这些确定性的外围工作中。
|
||
2. **上来做“全套”：** 在探索从单智能体到多智能体的演化时，团队下意识地就准备开始写代码，试图用框架和服务去编排一个尚未验证的流程。
|
||
3. **工作没头绪：** 尽管我划分了环节、定义了产出，但团队在每个环节上依然感到迷茫——我们知道“要做什么”，却不知道“该怎么做”。
|
||
|
||
那一刻我意识到，我们遇到的不是技术能力问题，而是一场深刻的工程思想的范式转移。我们熟练的、在信息化时代赖以生存的确定性工程思维，在智能化这个概率性的新大陆上，非但不是地图，反而成了误导我们的罗盘。
|
||
|
||
本文，就是我们团队在这场“思想阵痛”后总结出的六大核心原则。它旨在回答那个根本问题：在充满不确定性的世界里，如何以工程师的纪律和严谨，去构建可靠、有效的智能体？
|
||
|
||
这篇文章，是写给我的队员们，也是写给所有从确定性世界航向不确定性海洋的工程师们的开发宣言。
|
||
|
||
## 第一章：六大原则——我们在不确定性中航行的压舱石
|
||
|
||
从信息化到智能化，我们正在经历的转变，本质上是从构建“精确的建筑”到培育“有能力的生命体”。建筑的每一块砖都由我们精确定义；而生命体的行为则充满了概率性，需要我们去引导、约束和培育。以下六条原则，是我们避免在概率海洋中迷航，确保我们培育出的“生命体”能真正创造价值的行动指南。
|
||
|
||
### 原则一：拥抱混合工程——在确定性边界内，守护不确定的核心
|
||
|
||
我们过去的经验告诉我们，软件项目是确定的，是“1/0”的交付。但智能化开发的核心是概率性的，它的产出没有绝对的“完成”，只有“更好”。我们的第一个错误，就是试图用纯粹的确定性思维去规划整个概率性项目。
|
||
|
||
正确的范式是 **“混合工程”**。一个完整的智能化应用，本质上是一个**确定性工程外壳包裹着一个不确定性智能核心的混合体**。我们的首要任务，不是去构建那个坚固的外壳，而是要倾尽全力去探索和验证那个不确定的核心，看它是否能达到业务可接受的足够好的阈值。
|
||
|
||
对于会议纪要智能体而言，这意味着我们要暂时忘记用户管理，忘记权限控制，将全部精力投入到验证“能否在客户最关心的场景下，稳定生成高质量纪要”这一核心问题上。一旦这个核心价值被验证，那些外围的确定性功能才有存在的意义。否则，一个登录界面再精美的“无能”智能体，对客户而言价值为零。
|
||
|
||
**管理好确定性与不确定性这两种范式的边界与交互，是智能化项目管理的第一课。永远先让不确定性先走，让它为确定性工作圈定价值范围。**
|
||
|
||
### 原则二：“绿野仙踪”协议——编码前，先成为那个“幕后的人”
|
||
|
||
当团队准备直接用代码实现多智能体协作时，我叫停了。在流程本身都未被验证之前，任何代码都是对未来的过度承诺。我们必须先让流程“跑起来”，而成本最低、最灵活的方式，就是人肉模拟。
|
||
|
||
我们把这个阶段称为 **“绿野仙踪协议”**——让团队成员先在幕后扮演各个智能体的角色，手工协作完成一次完整的任务。比如，一个人扮演“会议录音转写Agent”，另一个人扮演“摘要与重点提炼Agent”，第三个人扮演“任务与待办事项识别Agent”，最后由我来扮演“最终报告生成与格式化Agent”。
|
||
|
||
这个协议的目的远不止于验证流程，它更是一个关键的知识发现过程：
|
||
|
||
1. **识别自动化的真正瓶颈：** 我们会立刻发现，哪些环节最耗时、最模糊、最依赖人类的“常识”判断。这些环节，正是自动化能带来最大价值的地方，也是技术攻关的真正靶心。
|
||
2. **捕获隐性知识：** 在协作中，我们会不断交流：“你这句话是什么意思？”“我需要你提供某某上下文才能继续。”……这些对话，就是未来构建高质量Prompt和Agent逻辑的“暗物质”。我们必须有意识地记录下这些在自动化后极易丢失的隐性判断和上下文补充。
|
||
|
||
**只有当人类能清晰、流畅地跑通一个协作流程时，我们才有资格去思考如何用代码将其自动化。**
|
||
|
||
### 原则三：从炼金术士到系统工程师——相信实测，而非“神话”
|
||
|
||
AI开发领域充满了诱人的“神话”和“魔法”，这让许多人兴奋地扮演起“炼金术士”的角色，通过神秘的仪式（调Prompt）和幸运的偶然，期待着“点石成金”的时刻。但作为工程师，我们的职责是将魔法置于科学的框架之下，**用实测去驯服不确定性，用数据去替代“感觉”**。
|
||
|
||
“百万Token上下文窗口”就是当前最大的技术神话之一。炼金术士会兴奋地将一部长篇小说直接扔给模型，然后祈祷它能理解；而工程师则会问：“在我的具体任务上，它的有效上下文窗口究竟是多大？”
|
||
|
||
我们会设计严谨的“大海捞针”测试，将一个关键信息点埋在不同长度、不同位置的文本中，来系统性地评估模型在长上下文中的信息召回能力。我们的实测结果，和许多同行的观察一致：**尽管模型能“吞下”超长文本，但当上下文超过某个阈值（例如4万字左右），它的注意力就会显著“失焦”，性能开始不稳定。**
|
||
|
||
相信神话，会让我们构建出看似强大但脆弱不堪的系统。而相信实测，则会引导我们做出明智的工程决策：我们认识到，当前阶段，**构建稳定、高效的RAG系统，或者设计智能的摘要链来处理长文本，是远比盲目信仰“超长上下文”更可靠的工程路径。**
|
||
|
||
**工程师的使命，不是追逐魔法，而是为魔法的稳定复现，搭建一个可度量、可预测、可优化的系统。**
|
||
|
||
### 原则四：过程即数据——像珍惜代码一样，珍惜每一次交互与修正
|
||
|
||
“数据是所有智能化的前提”，这句话我们耳熟能详。但我们的认知常常局限于将“数据”等同于项目启动时的“原始输入”——比如客户提供的会议录音或文档。这远远不够。在智能体开发的全生命周期中，一种更宝贵、更鲜活的数据正在被我们不经意地忽略。
|
||
|
||
我称之为 **“过程数据（Process Data）”**。
|
||
|
||
在执行“绿野仙踪协议”时，团队成员的每一次人工操作、每一次对AI草稿的修改、每一次为了让流程跑通而进行的讨论和决策——这些看似琐碎的交互与修正，**本身就是最顶级的、标注精良的训练数据**。
|
||
|
||
* 当一个成员修改了AI生成的摘要，这个“修改前”与“修改后”的对比，就是一条完美的指令微调样本，它精确地告诉了模型：“在这种情况下，人类专家认为这样的输出更好。”
|
||
* 当一个成员为了完成任务，去额外查找并补充了一段背景信息，这个行为本身就在定义一个高质量上下文应该包含哪些要素。
|
||
* 我们用来评估智能体输出好坏的案例，不应该凭空捏造，而应该直接源自于这些在真实流程中发现的、最棘手的、最能体现能力的“边界案例”。
|
||
|
||
因此，我们必须建立机制，像用Git管理代码一样，系统性地捕获和管理这些过程数据。它们是我们提炼精准指令、构建高相关性Few-shot示例、打造那套“小而美”评测集的黄金矿藏。**忘记捕获过程数据，无异于一边开采金矿，一边将最纯的金沙随手丢弃。**
|
||
|
||
### 原则五：深度优先于广度——打穿一个点，好过抚摸一个面
|
||
|
||
面对一个新项目，工程师的本能是设计一个具有良好扩展性、能够覆盖所有潜在场景的通用架构。这种“广度优先”的思维在确定性世界里是美德，但在不确定性世界里，却可能成为致命陷阱。因为它会让我们在验证任何一个单点价值之前，就耗尽所有资源。
|
||
|
||
智能体开发，必须遵循深度优先（Depth-First）的原则。
|
||
|
||
这意味着，我们要抵制住构建“通用会议纪要平台”的诱惑，转而选择一个极度狭窄的垂直切片作为突破口。比如，我们不去支持所有类型的会议，而是只聚焦于“客户销售团队与潜在客户的首次接触会议”。
|
||
|
||
然后，我们将全部火力集中于这个点，把它打穿、打透。我们在这个极小的场景里，完整地走完从 **“绿野仙踪协议” -> 自动化实现 -> 过程数据捕获 -> 评测 -> 迭代优化**的全流程闭环。
|
||
|
||
这个过程的好处是巨大的：
|
||
|
||
1. **快速获得正反馈：** 在一个小场景里做到95分，远比在十个场景里都做到60分更能建立团队和客户的信心。
|
||
2. **沉淀核心资产：** 我们在这个过程中打磨出的Prompt框架、评测脚本、数据处理流程，都会成为可复用的核心资产。
|
||
3. **真正的敏捷：** 当我们彻底征服了一个点之后，再将这套被验证过的模式“复制-粘贴-微调”到下一个场景，速度和成功率将远超一开始就试图构建通用平台。
|
||
|
||
**能做好一件事，你才真正拥有了能做好所有事的能力基础。** 在智能体开发中，打穿一个点的深度，决定了你未来拓展一个面的速度。
|
||
|
||
### 原则六：保持信号过滤噪声——在喧嚣中构建自己的认知护城河
|
||
|
||
AI领域每天都充斥着各种令人焦虑的“突破”和“颠覆”。今天“RAG已死”，明天“提示词工程过时”，后天又出现了某种全新的“XX工程”。如果我们的认知和战略随着这些头条新闻摇摆，团队将永远处于追逐潮流的疲于奔命中，无法积累下任何有价值的东西。
|
||
|
||
作为工程师和技术领导者，我们必须要有强大的定力，**在铺天盖地的噪声中，过滤出真正有价值的信号，并构建起团队自己的认知护城河。**
|
||
|
||
我们的态度应该是 **“战略上藐视，战术上审视”**。
|
||
|
||
* **战略上藐视：** 意味着我们要坚信底层逻辑。比如，无论“上下文工程”这个词如何包装，其内核依然是围绕着如何为模型提供高质量的指导性、信息性和行动性上下文，这与RAG和提示词工程的本质一脉相承，也完全在我们CCPE框架的射程之内。我们不为新词所惑，不为焦虑所动。
|
||
* **战术上审视：** 意味着我们要对新的概念保持开放和好奇。一个新词的流行，往往反映了行业焦点的变化或在某个方向上的认知深化。我们要去审视它背后是否带来了有价值的新视角或新工具。如果有，就批判性地吸收其精华，用它来丰富和强化我们自己的框架体系。
|
||
|
||
例如，我们看到“上下文工程”的讨论后，并没有抛弃CCPE，而是反思如何在CCPE的“操作层”中，更系统地去设计和管理“信息性上下文”的注入策略。这就是一种积极的、有定力的演进。
|
||
|
||
**真正的定力不是顽固不化，而是在坚持核心原则的基础上，持续将外界的有效信号，转化为自己认知护城河上的一块块新砖。**
|
||
|
||
## 第二章：原则的固化——我们的工程框架CCPE
|
||
|
||
原则若无框架承载，便如飘浮空中的信念，难以落地生根。反之，框架若无原则指引，则易沦为僵化的教条。在我们团队，将上述六大原则凝聚并付诸实践的工程脚手架，就是**CCPE——智核提示工程（Cognitive Core Prompt Engineering）**。
|
||
|
||
在经历了最初的混乱后，我们意识到，必须有一个结构化的工具，来强制我们在编写任何Agent代码之前，先行完成对那个“不确定核心”的系统性思考。CCPE因此而生，它不是一个简单的Prompt模板，而是一个**引导工程师像设计精密系统一样，去设计Agent心智模型的思考框架**。
|
||
|
||
CCPE的四个层次，正是我们六大原则的具体体现：
|
||
|
||
* **核心层 (Core Layer - “我是谁”)：** 这一层强制我们回答Agent的基础身份、核心价值观和推理偏好。这直接服务于“深度优先”原则，让我们在开始之前，就必须为一个“垂直切片”的场景定义一个清晰、专注的角色，而不是一个模糊的“全能助手”。
|
||
* **执行层 (Execution Layer - “我能做什么”)：** 这里界定了Agent的功能范围、知识边界和决策权限。这是对“混合工程”原则的直接应用，它让我们清晰地划定了“不确定核心”的能力边界。哪些是它可以自主决策的，哪些是它必须交由人类或确定性程序处理的，都在这里被严格定义。
|
||
* **约束层 (Constraint Layer - “什么不能做”)：** 通过设定硬性与软性约束，我们为Agent的行为划定了不可逾越的红线。这呼应了“从炼金术士到系统工程师”的转变——我们不再寄望于模型的“自觉”，而是通过明确的工程纪律来确保其行为的安全、合规与可靠。
|
||
* **操作层 (Operation Layer - “如何做”)：** 这是整个框架的执行核心，定义了从任务解析、工作流程到异常处理的完整逻辑链。它完美承载了“绿野仙踪协议”的产出，将我们在人工模拟中捕获的那些“过程数据”和隐性知识，转化为Agent可执行的、结构化的工作流。同时，对输入处理与上下文管理的关注，也正是对“过滤噪声，构建护城河”原则中，如何系统性应用高质量上下文的工程化回答。
|
||
|
||
CCPE强迫我们在面对大模型的浩瀚能力时，保持工程师的冷静与克制。它引导我们先思考，再设计，后编码。它是一个规训我们思维的工具，确保我们培育出的每一个智能体，从诞生之初，就被置于严谨的工程哲学之上。
|
||
|
||
## 结语：致我的团队，以及每一位智能时代的开拓者
|
||
|
||
写下这篇宣言，既是对我们过去几周“思想阵痛”的一次复盘，也是为我们接下来的征程树立的一面旗帜。
|
||
|
||
致我的队员们：从Java到AI，我们正在经历一场激动人心且极具挑战的迁徙。我们熟悉的确定性世界正在远去，但这并不意味着我们要抛弃过去二十年所积累的宝贵财富——那种严谨的、追求可靠与可维护性的工程师精神。恰恰相反，在充满概率与涌现的智能化新大陆，这种精神将是我们最稀缺、最核心的竞争力。
|
||
|
||
我们失去的，只是确定性的安逸；而我们将获得的，是亲手创造智能的无限可能。
|
||
|
||
这条路没有现成的地图，充满了不确定性。但正如我们所信奉的，慢，才是最快的速度。只要我们坚持正确的原则，使用CCPE这样的结构化工具，保持耐心和定力，一步一个脚印地去思考、实践、迭代，我们终将“快”速抵达智能时代的未来，并成为那里最优秀的建筑师。
|
||
|
||
共勉。
|
||
|
||
---
|
||
|
||
## 参考阅读
|
||
|
||
* [智道清领书](https://sayings.wantsong.life/post/2025-04-12-ai-cultivation-manual/)
|
||
* [从软件工程师到AI工程师，我们扔掉的第一件东西是确定性](https://sayings.wantsong.life/post/2025-08-12-from-software-engineer-to-ai-engineer/)
|