一、最近用AI做了哪些事？
1. 自己动手做了一个解压缩软件
事情是这样的，前几个月的某天在公司里，我下载一个压缩包准备解压，突然发现系统默认的解压缩软件还得花钱。
我平时很少用到解压缩软件，为了一次使用再花几十块钱总觉得不值。于是，我索性试着用 vibe coding 自己动手写一个——结果真的很诧异，竟然顺利做出来了，而且成功把压缩文件解压了出来。
2. 自己动手搞了个酒店价格库存查询工具 + 可预订网站
我负责酒店分销平台，很多分销商经常反馈有些酒店库存没了、价格变了。内部的运营部门、销售部门也需要统计全国实时酒店价格，或者查询某个城市可订的酒店等等。这类需求一直不少。
公司虽然有一套后台系统能查单个酒店的价格，但异常难用——每次查询得先搜酒店，再点房型，最后才能看到日历价格。
如果我正儿八经提个新需求给技术部门，估摸着至少得排期一周才能搞定。我就干脆自己动手，打开我的“小龙虾”开始开发。我先找研发要了 API 接口文档和账号，自己给自己写了一份简单的 PRD 文档，然后让“小龙虾”干活。前后大概不到两个小时，一个能在本地运行的酒店查询系统就出来了。
输入城市和日期，所有酒店的房型、报价、库存、房态一次性全部拉出来，还支持导出。
本地电脑安装版：
Web 版：
3. 我开始用 Agent 做 Agent 产品
这个项目的背景是公司也要开发自己的预订 Agent，想法挺好。可惜的是，需求提给技术部门，反馈的结果是这种 Agent 开发他们也不会，让产品经理自己来。刚好公司采购了企业版的“coze”——一个能自己搭建工作流的平台。
好家伙，研发直接甩给产品自己干活了！
我就开始研究这个工作流平台，看能不能真的开发出我们想要的 Agent。先说结论：可以是可以，不过对大部分产品经理来说，学习成本依然不低。绝不是简单拖拽几个节点那么容易，需要调试各种参数，搞清楚变量怎么定义、API 怎么调用，还有各种逻辑关系的编排。
我是怎么学的呢？我粗略算了算，要完成这个预订 Agent，至少也得搭建七八个工作流，涉及几十个接口调用编排。如果自己零基础慢慢摸索，把所有工作流完整搭出来，那得猴年马月？关键是自己能不能完全搞定也充满未知。
我的办法是——用 Agent 来帮自己搞定 Agent 的产品设计和开发（用 Claude Code 来编程）。
二、未来会发生哪些变化？
第一、岗位的变化
互联网公司颠覆了传统软件公司，而现在 AI 公司正在颠覆传统的互联网公司。就拿我上面亲身的例子来说。
例：开发一个内部查询酒店价格库存的程序
- 传统互联网开发模式：产品经理写需求 1 天 → 研发排期 0.5 天 → 前端研发 2 天 + 后端研发 2 天 + 测试 1 天，一周过去了！
- AI 公司模式：产品经理写需求 1 小时（AI 辅助写） → 全栈工程师开发 0.5 天（AI 编程实现），不到 1 天搞定上线。
产品经理都能独立开发一个内部程序了，为什么还要按照传统模式分别找一个前端工程师和一个后端工程师来做呢？
第二、组织的变化
当产品经理开始自己动手写代码，甚至用 AI Agent 完成开发任务时，最先感受到震动的不是技术本身，而是组织架构。
传统互联网公司的项目管理，遵循着层层递推的线性逻辑。一个需求从产品经理提出，到技术评审、排期、开发、测试、上线，每个环节都需要专门的岗位和部门协作。这种分工明确的科层制结构，在过去二十年里支撑了互联网的高速发展。但 AI 时代的到来，让这套体系的效率瓶颈暴露无遗。
我做那个酒店库存查询工具，如果走传统流程：先写需求文档，开评审会，技术评估排期一周，开发两周，测试一周，上线部署一天。整个过程至少一个月，涉及产品、后端、前端、测试、运维五个岗位的协作。而我自己用 Python 写，加上调试和部署，只用了三个晚上。
这不仅仅是个人效率的提升，更是对组织分工逻辑的根本挑战。
项目管理：从层层递推到一人搞定
传统项目管理依赖的是“信息传递链”。产品经理把需求传递给技术负责人，技术负责人拆解任务分配给开发，开发完成后交给测试，测试通过后交给运维。每个环节都是信息漏斗，都会产生损耗和延迟。
在 AI 时代，这个链条被压缩到了极致。产品经理可以直接用自然语言描述需求，AI Agent 就能自动拆解任务、生成代码、运行测试、部署上线。中间的所有协调环节都被自动化了。
这意味着什么？意味着项目管理的核心从“协调人”变成了“定义问题”。过去项目经理 70% 的时间花在沟通协调、进度跟踪、风险预警上；现在这些工作被 AI 接管，项目经理需要把精力聚焦在真正重要的事情上：如何准确定义业务目标，如何设计合理的验收标准，如何确保 AI 产出的质量符合预期。
组织不再需要庞大的项目管理团队来维持流程运转。一个资深的产品经理或技术负责人，配合几个 AI Agent，就能完成过去需要十几人团队的活儿。
岗位边界模糊：产品 vs 技术的职责重新划分
“产品经理不懂技术”曾经是行业共识，甚至是某种分工合理性的证明。产品负责业务逻辑，技术负责实现细节，各司其职。但现在，这个边界正在快速消融。
当我开始自己写代码时，我发现产品经理和技术人员的思维差异，很大程度上源于信息不对称。产品经理不知道某个功能的技术实现成本，技术人员不理解某个需求的业务价值。这种信息差导致双方在评审会上各说各话，最终靠权力或妥协达成一致。AI 消除了这种信息差。产品经理可以直接用代码验证自己的想法，技术人员也能通过 AI 快速理解业务场景，双方站到了同一个信息平面上。
未来的组织里，“产品经理”和“技术负责人”可能不再是两个独立的岗位，而是同一个人的两种能力维度。这个人需要既懂业务又懂技术，既会定义问题又会指挥 AI 解决问题。毕玄提出的“Agent 工程师”概念，正是这种融合趋势的体现——不再区分前后端、测试、运维，所有技术岗统一为能够指挥 AI 完成全栈开发的超级个体。
这种融合不是简单的岗位合并，而是能力结构的重构。传统技术人员的核心竞争力是编码能力，未来则变成问题定义能力与 AI 指挥能力。传统产品经理的核心是需求分析能力，未来则变成技术判断能力和系统设计能力。
组织扁平化与小型化趋势
AI 带来的效率提升，直接冲击了组织的规模假设。过去，企业规模越大，分工越细，被认为效率越高。因为专业化分工能降低学习成本，提高单个环节的熟练度。但 AI 让一个人就能掌握多个专业领域的能力，专业化分工的优势被大幅削弱。
相反，小型团队的优势凸显出来：决策链条短，沟通成本低，响应速度快。两个人用 AI 在三个月内做出需要 40 人团队三个月才能完成的产品，这种案例正在从个例变成趋势。
组织形态正在从“金字塔”向“沙漏”转变。顶层是少数战略决策者，底层是大量高度自主的 Agent 工程师，中间的管理层被大幅压缩。AI 充当了“智能中间件”，替代了传统中层管理者的协调、监督、质量控制职能。这种扁平化不是简单的裁员，而是组织运行逻辑的升级。过去管理者需要监督下属的工作过程，确保执行质量；现在只需要定义目标，验收结果，过程由 AI 自主完成。
更深刻的变化在于，组织从“机械系统”转向“有机系统”。传统组织像一台精密钟表，每个部件可拆可装，遵循还原论逻辑。而 AI 组织更像生命体，各子系统深度耦合、相互依存，具有上下文感知、持续微调、动态演化的特性。在这种有机组织中，岗位职责不再是固定不变的职位描述，而是根据任务需求动态组合的能力集合。
这种变化对企业的管理能力提出了全新要求。AI 时代的企业竞争，将越来越取决于组织设计的先进性。那些能够快速适应人机协同新范式，构建灵活、扁平、有机组织形态的企业，将在效率和创新上获得决定性优势。
第三、工作范式的变化
当人类从直接执行者转变为 AI 指挥官，工作范式发生了根本性重构。
传统工作模式基于“岗位本位”——个人被固化在某个职位上，执行一套相对固定的职责。AI 打破了这个前提，一个人配合多个 AI Agent，就能完成过去一个团队的工作。工作模式从“岗位本位”转向“任务本位”——工作被拆解为细颗粒度的任务单元，动态分配给最合适的执行者：人类或 AI。
人类从工作者到指挥官的角色升级
这种转变不是简单的效率提升，而是角色定位的质变。过去，人类是“功能的实现者”。老板说“写一份市场报告”，你打开 Word，搜索数据，整理图表，敲击键盘。你是生产流水线上的核心劳动力。现在，人类转变为“能力的发现者与训练师”。你不再直接撰写每一个字，而是理解 AI 模型的能力边界，通过设计指令链引导 AI 产出初稿。你从“划船的人”变成了“掌舵的人”。
火车头工程师驱动多个 AI Agents 协同
最典型的工作场景是“火车头工程师”模式：一个资深技术专家作为“火车头”，指挥多个 AI Agent 协同工作。这个工程师不再亲自写代码，而是定义系统架构、设计接口规范、制定验收标准。具体的编码、测试、文档生成等工作，由不同的 AI Agent 分工完成，工程师只需在关键节点进行质量审查和方向校正。
这种模式成倍放大了个人杠杆。工作产出不再受限于个人的编码速度，而取决于个人的系统设计能力和 AI 指挥能力。更重要的是，它实现了“个性化服务的规模化交付”。一个工程师可以同时服务多个客户，为每个客户定制不同的方案，而成本几乎不变。
人+Agent 的新协作关系
人机协作从“主从工具”模式，迈向“意图驱动、智能协同”的新阶段。传统的人机交互是“人操作系统”——人类需要理解复杂界面、判断操作路径。在智能体时代，交互模式转变为“人指挥智能体”——人类不再关注具体的“如何做”，而是直接“描述目标”，系统负责自动拆解与执行。
这种协作关系催生了“半人马模式”——人类智能与 AI 能力深度结合。人类擅长战略思考、复杂判断、理解微妙情境；AI 擅长数据处理、模式识别和快速执行。工作流程被重新设计，以充分利用这些互补优势。持续学习和适应能力由此成为核心生存技能。
第四、软件工程的变革
AI 正在推动软件开发从传统的编码模式，向意图编程范式演进。
传统软件工程遵循需求分析、设计、编码、测试、维护的线性流程。AI 的引入使这一流程呈现出迭代化、动态化特征。编程环节的自动化仅是表象，更深层的变革在于需求沟通、方案设计与品控测试等全流程的效能提升。
敏捷开发升级为智能化编配
敏捷开发的核心是快速迭代、持续交付。AI 将这一理念推向极致，实现智能化编配。需求变更的响应时间从平均 3 天压缩至 2 小时。AI 不仅自动化了编码，更自动化了测试、部署、监控的全流程。传统敏捷依赖人工协作，AI 时代敏捷依赖智能体协同。
需求-开发-测试的流程重构
需求管理从静态文档交付转向动态价值创造。开发流程由线性接力变为异步并行，AI 参与需求理解、架构设计、代码生成、自动测试、智能部署每一个环节。人类角色从纯粹执行者转为智能体编排者，聚焦定义成果目标、界定资源边界、设立验收标准三大战略职责。测试环节则构建了无需人工质检门的智能质量闭环。
传统岗位 skill set 的重定义
开发者社群出现“圈层分化”。顶层是掌握提示工程与模型微调的 AI 训导师，主导需求定义与系统架构设计；中层转型为代码策展人，负责审核优化 AI 输出；底层传统 CRUD 程序员面临转型压力。软件工程教育的目标也从“熟练编码”转向“系统思维”与“架构能力”。
AI 驱动的软件工程范式，本质上不是岗位替代，而是能力升级。它将人类从重复性劳动中解放出来，让我们能更聚焦于创造性的判断与战略决策。
说到这儿，不知道正在读文章的你有没有类似感受？当你发现自己也能像全栈工程师一样去实现想法时，那种边界被打破的感觉其实很奇妙。技术的进步终归是服务于人，而作为开发者或者产品人，我们要做的可能就是保持好奇，持续上手折腾。
发表于 2 小时前
|
查看: 4|
回复: 0
