一、不懂管理的管理
我从不认为自己懂管理。过去更多是扮演"带头冲锋"的角色——事无巨细，亲自上阵做产品、写代码、抓工程。
今年年初的组织调整，让我开始深度思考管理的本质。我做了三个改变：
1. 主动放权
强化PDT组织，以市场为导向驱动研发
理顺协作关系，让专业的人做专业的事
风险问题收集信息，敢于决策，不会模糊化处理让团队担风险
2. 激励为主
通过 PDT 增量分享与齿轮项目，以激励为主
不担研发成本，收入全算，通过组织和激励制度设计推动产品创新
3. 自我约束
多看、多听、多想、多写，少说
定方向、定原则、给支持，避免事无巨细的干预
日常管理做好观察者，虽然只参加部分周会，但是认真看邮件、看 wiki，主动去了解、去聊，而不是天天折腾团队做汇报
ID、UI 等主观问题不发表意见，细节执行问题少发表、后发表意见
最近研究AI Agent工程时，我突然发现：AI提示词工程的演进，和组织管理的演进，惊人地相似。
眼下，貌似又到了一个“组织变革”的时候，我不懂管理，但是略懂AI，结合AI Agent，对组织管理有些思考，做一些反思、总结。
二、Prompt 工程从Workflow到React的转变
早期：手把手教AI做事（Workflow）
在GPT-3.5时代，我们是这样写提示词的：
你是客服助手，严格按以下步骤操作：
步骤1：判断用户问题类型
- 如果是退款，跳转步骤2
- 如果是咨询，跳转步骤3
- 如果是投诉，跳转步骤4
步骤2：退款流程
- 先说"非常抱歉给您带来不便"
- 然后询问订单号
- 接着查询订单状态
- 最后按模板回复...
示例1：
用户："我要退款"
助手："非常抱歉给您带来不便，请提供您的订单号..."
示例2：...
示例3：...这种是 Prompt 的 Workflow 写法：
依赖严格的Workflow设计
通过Step-by-step约束流程
大量Few-shot examples保证输出质量
类似"流水线工人"：每个环节都要详细规定
为什么要写得这么详细？因为模型能力弱，不详细指导就会"胡说八道"，就不会有稳定的产出。
这就像目前的供应链和品质管理，流水线上的员工相对能力较差，人员流动性高，没有经验沉淀积累，必须手把手教，必须落到详细的SOP 上，还得有交叉的检查机制，否则就会出错。
现在：告诉AI目标，让它自己想办法（React）
到了GPT-4/Claude-3.5时代，提示词变成了这样：
你是高级客服专家。
核心使命：让每个用户感受到被重视，问题得到妥善解决。
行动原则：
1. 同理心优先 - 先理解用户情绪和真实诉求
2. 系统思考 - 考虑问题根因，而非头痛医头
3. 主动担当 - 在权限内最大化解决问题
4. 持续优化 - 记录特殊案例，改进服务
可用工具：
- search_kb(关键词): 搜索知识库
- query_order(订单号): 查询订单
- escalate(问题描述): 升级人工处理
评估标准：
- 用户满意度评分 > 4.5
- 问题一次解决率 > 80%
现在开始处理用户请求，展示你的思考过程：
Thought（思考）→ Action（行动）→ Observation（观察结果）→ Reflection（反思）这是 Prompt 的 React写法：
转向Goal-oriented的React模式
给定目标和原则，让模型自主规划
Thought → Action → Observation 循环迭代
类似"知识工作者"：理解意图后自主完成
同样是处理客服问题，但方式完全不同：
以前：详细规定每一步怎么做（Control）
现在：明确目标和原则，让AI自主决策（Context）
为什么可以这样？因为模型能力变强了，它有了推理、规划、自我反思的能力。
对于产研团队，本身从事的是有一定创造性需求的研发工作，无论是从学历上还是经验上，我们很多同事都不差，你只需要说清楚目标和可用资源，他自己就能找到最佳路径。硬性的限制和耳提面命式的管理，反而会激起大家的逆反心理，发挥不出大家的能力和创造性。管的累，还管不好。
三、Context, not Control
字节跳动创始人张一鸣有个著名的管理理念：Context, not Control（给上下文，而非控制）。
在 AI Agent 的工程项目中，最重要的也是 Context，有高度的相通性。
Context工程与管理的相通性
1. 上下文窗口 vs 信息透明度
深层共通性:
Agent需要"上下文管理策略"(什么信息保留/丢弃)
团队需要"信息架构设计"(什么信息公开/隐藏)
两者都在解决信息过载与信息不足的平衡
2. Prompt Engineering vs 目标对齐
AI Agent层面:
System Prompt定义Agent的角色、能力边界、行为准则
好的 Prompt 往往包含一些“PUA”和捧杀，不给任何理由，你是一个什么专家，你一定可以完成什么任务
类似给Agent一个"价值观"和"行动指南"
好的Prompt让Agent无需每次都详细指令
团队管理层面:
OKR系统确保个体目标与组织战略对齐
清晰的Context让员工自主判断"什么该做、什么不该做"，什么时间点该做什么，有统一的原则不会瞎折腾
给到明确的目标和激励，不给任何失败的接口和理由，一鼓作气
共通点: 都是通过预设Context(价值观/目标)减少实时控制需求。
3. Few-shot Learning vs 案例传承
AI Agent层面:
通过提供少量示例(Few-shot)让Agent理解任务模式
示例本身就是一种Context,帮助Agent泛化能力
团队管理层面:
强调"复盘文化"和"最佳实践沉淀"
通过案例库、项目回顾让新员工快速理解"怎么做事"
减少手把手指导(Control),依靠案例Context自学习
共通点: 都通过历史经验作为Context实现知识传递和能力复制。
4. 上下文刷新 vs 信息同步
AI Agent:
需要定期更新Context(如新的用户偏好、环境变化)
Long-term Memory机制保持关键信息持久化
避免"遗忘"重要背景导致决策偏差
团队管理:
实时数据看板、周会同步
OKR季度更新,保持目标与市场环境对齐
公开透明的管理工具确保信息实时流动
即使刷新去除过时、无效信息，不要让团队困惑
共通点: 都需要Context的时效性管理,过时、杂乱的Context比没有Context更危险。
5. 上下文优先级 vs 信息筛选
AI Agent:
面对海量信息,需要Ranking机制(如RAG的相似度排序)
核心Context优先加载,次要信息按需检索
团队管理:
"简化规则,减少冗余"
不是所有信息都需要透明,而是关键Context必须透明
避免信息噪音干扰决策
共通点: 都在解决Context质量>Context数量的问题。
6. 过度Context的风险
AI Agent:
Context污染:无关信息干扰推理
Context冲突:矛盾信息导致混乱
隐私泄露:过度共享敏感信息
团队管理:
信息过载:员工陷入"分析瘫痪"
透明度焦虑:过度暴露导致心理压力
竞争内耗:内部赛马机制的负面效应
共通点: 都需要Context的边界管理,并非越多越好。
深层哲学的统一性
1. 信任与赋能
AI Agent: 相信模型在充分Context下能做出合理决策
团队管理: 相信优秀人才在充分信息下能自主创新
本质: 都是从"不信任→严格控制"转向"信任→充分赋能"
2. 涌现性思维
AI Agent: 复杂智能行为从简单规则+丰富Context中涌现
团队管理: 组织创新从个体自主+信息透明中涌现
本质: 都相信系统智能>个体智能之和
3. 反脆弱性
AI Agent: 通过多样化Context训练,提升泛化能力
团队管理: 通过信息开放和内部竞争,增强组织韧性
本质: 都通过增加Context多样性而非加强Control来应对不确定性
从AI Agent的演进，我们看到一个清晰的规律：
系统智能 = Context质量 × 决策能力 × 行动自由度当决策能力弱时（GPT-3.5 / 初级员工、工厂流水线）：
需要详细的Control补偿
这是必要的，不是坏事
当决策能力强时（GPT-4 / 产品研发、资深员工）：
过度Control会限制潜力
应该转向Context赋能
但无论如何：
Context质量是基础
没有好的Context，再强的能力也发挥不出来
"Context, not Control"与AI Agent的上下文管理本质上都在解决同一个问题:
如何在复杂、动态、不确定的环境中,通过信息架构而非权力结构,实现分布式智能体的高效协同?
这个问题的答案不是"更强的控制",而是"更好的Context":
AI Agent需要的不是更多规则,而是更准确的上下文
团队成员需要的不是更多指令,而是更清晰的信息
两者的共通性揭示了一个深刻的管理哲学:智能的本质是信息处理,而非权力执行。无论是硅基智能还是碳基智能,充分的Context都是自主决策的前提。
对团队成员来说
战略Context：
公司今年的OKR是什么？
我们在市场上的位置如何？
竞争对手在做什么？
业务Context：
当前项目的优先级如何？
有哪些资源可以调用？
关键决策的背景是什么？
执行Context：
相关的技术文档在哪里？
过去类似项目的经验教训？
遇到问题可以找谁？
反馈Context：
我的工作效果如何？
哪些地方需要改进？
团队对我的期待是什么？
四、业绩不好就折腾组织？这是最糟糕的Control
当业绩下滑时，很多领导的第一反应是调整组织，这是典型的 Control 思维。类似一个 Agent 没有得到预期的结果，不去检查 Prompt，不去检查各环节的输入输出，上来就要改技术架构实现。
典型的"Control思维"
频繁调整组织架构：
"我们要学阿里的'中台战略'"
"不行，改成'大前台小中台'"
"还是不行，学华为搞'铁三角'"
事无巨细的瞎指挥：
"这个按钮要改成红色"
"技术栈必须用我说的那个"
"每天下班前给我汇报进度"
增加流程和检查：
"每周写三份报告"
"所有决策必须我批准"
"成立专项小组监督执行"
为什么这样做？
因为领导者陷入了业绩焦虑和控制幻觉：
"业绩不好 = 团队执行不力 = 我管得不够细 = 要加强控制"
这就像AI开发者遇到模型效果不好，就拼命增加规则：
# 越写越复杂的Prompt
if 用户说A:
回复B
elif 用户说C:
回复D
elif 用户说E:
if 情况1:
回复F
elif 情况2:
if 子情况1:
回复G
...结果呢？根本问题没解决，系统越来越僵化，遇到新情况就崩溃。
何时需要Control？
Context, not Control 不是说完全不要Control，而是要最小化必要的Control。
必须Control的场景
1. 安全和合规底线
组织场景：
财务合规：大额支出必须审批
安全生产：必须遵守安全规范
法律红线：不能触碰的底线
2. 重大不可逆决策
组织场景：
战略方向调整
关键人事任命
3. 能力明显不足时
组织场景：
新员工需要详细的培训和指导
新业务初期需要更多的介入
团队能力与任务复杂度不匹配
Control的原则
1. 最小必要集： 只在真正必要的地方Control
2. 透明化： 让大家理解为什么需要这个Control
不要说："这是规定，必须执行"
而要说："因为XX风险，所以需要XX审批"3. 动态调整： 随着能力提升，逐步放开Control
新员工：详细指导（Control）
→ 熟练员工：原则指导（Context）
→ 资深员工：目标授权（Context）4. 例外机制： 允许在特殊情况下突破Control
"正常情况下需要审批，但紧急情况可以先做后报"结语：智能的本质是信息处理，管理的本质也一样
无论是AI Agent还是人类组织，智能的本质都是信息处理能力。
一个公式：
系统智能 = Context质量 × 处理能力 × 行动自由度Context是基础： 没有好的Context，再强的能力也发挥不出来
AI没有相关知识就会胡编
员工不知道战略就会盲目执行
Control是补偿： 当能力不足时，Control是必要的
GPT-3.5需要详细Prompt
初级员工需要详细SOP
自由是释放： 当能力充足时，过度Control会限制潜力
GPT-4可以自主React
资深员工可以自主决策
当业绩不好时，不要急着折腾组织、加强管控。
先问自己：
团队有足够的Context吗？ （信息透明度）
团队有足够的能力吗？ （人才和培训）
团队有足够的自由吗？ （决策权和资源）
好的管理者提供Context，让团队自主决策，差的管理者依赖Control，让团队被动执行，就像AI一样：
强模型需要的是好的Context，而不是复杂的规则
弱模型才需要手把手教
我们有这行业较高的人才密度，学历、背景、经验都不差，我们的员工和团队是强模型还是弱模型？这个组织是 Control 不足还是 Context 混乱？
如果是强模型，为什么还要当成弱模型来管？
评论