110 lines
13 KiB
Markdown
110 lines
13 KiB
Markdown
---
|
||
layout: post
|
||
title: "从软件工程师到AI工程师，我们扔掉的第一件东西是确定性"
|
||
subtitle: ""
|
||
date: 2025-08-12 18:50:00
|
||
author: "Wantsong"
|
||
keywords: "AI开发, 软件工程师转型, 确定性思维, 认知建模, 思维范式, AI产品开发, 惯性陷阱, 智能化转型, 人机协同, AIGC, 大语言模型, 业务建模"
|
||
description: "本文通过一个真实的AI产品（会议纪要智能体）开发故事，深入探讨了软件工程师转型AI开发时面临的最大挑战：抛弃根深蒂固的“确定性”思维。文章剖析了团队如何从专注于UI和功能的“惯性陷阱”中走出，并提出从“业务建模”转向“认知建模”的核心理念。这不仅是一次技术实践的反思，更是一份关于如何在AI时代“把事情做对”的思维升级指南，为所有探索智能化的工程师和团队提供了一条清晰的路径。"
|
||
params:
|
||
published: true
|
||
tags: ["Original","Thinkpiece","CrossoverWriting","BizWriting","CognitiveScience"]
|
||
image: "https://imgs.wantsong.life/pc8PXCoZOD.jpg"
|
||
categories:
|
||
- "THINKING"
|
||
- "SocialTech"
|
||
---
|
||
|
||
“这不像是AI直接生成的，人加工的成分更多吧？”
|
||
|
||
当我的朋友，一位同样在AI领域摸索的同行，看到我们团队打造的会议纪要智能体生成的报告时，她带着三分审视、七分怀疑地问道。
|
||
|
||
听到这句评价时，我心里咯噔一下，但随即竟有些哭笑不得的欣慰。因为她说对了一半。这份纪要确实没有经过任何人工的二次修改，但她差点就说中了——因为在几个月前，我们亲手打造的那个版本，如果不经人工润色，简直不忍卒睹。
|
||
|
||
我们团队的背景清一色是软件开发工程师，随着AI浪潮席卷而来，转型是必然。为了快速切入，我们选择了一个看似简单、实则暗礁丛生的引流产品：会议纪要智能体。用户上传一段会议录音，系统自动生成一份结构化的纪要。它很轻，价格也便宜，目的是让那些对AI还不太了解的客户，能直观地感受到智能化的魅力。
|
||
|
||
但与客户和朋友的交流，常常让我陷入一种割裂感。他们对AI的认知，精准地分布在两个极端：要么是神化派，觉得喂给AI几年的销售数据，它明天就能预测出全年的业绩；要么就是像我这位朋友一样的存疑派，骨子里不相信AI能真正胜任严肃、精准的工作。
|
||
|
||
而我朋友的这句“冒犯”，恰好精准地刺中了我们转型之路上的第一个，也是最深的一个痛点。从一个需要大量人工返工的半成品，到一个连挑剔同行都觉得“好到不像AI”的产品，我们究竟经历了什么？这趟旅程的核心，并非代码的迭代，而是一次痛苦但必要的思维范式迁徙。我们扔掉了一样东西，一样我们这些软件工程师最熟悉、最依赖的东西。
|
||
|
||
---
|
||
|
||
故事要从我们团队的基因说起。我们是一群在软件工程世界里摸爬滚打了多年的老兵，信奉逻辑、精确和边界。我们习惯于将现实世界的混乱，抽象成清晰的数据结构、明确的业务流程和无歧义的代码。输入A，必须输出B，这是我们刻在骨子里的信条。
|
||
|
||
所以，当会议纪要智能体这个项目启动时，我们几乎是本能地，就走上了一条看起来无比正确的“老路”。
|
||
|
||
我们的讨论焦点，迅速集中在了那些我们最擅长、最熟悉的部分：
|
||
|
||
* “这个界面是不是可以更酷炫一点？用户上传的动效要流畅。”
|
||
* “Markdown格式不够正式，必须支持一键导出Word和PDF，格式要完美兼容。”
|
||
* “要不要增加一个即时语音转文字功能？虽然可能用得不多，但显得很强大。”
|
||
* “我们应该提供一个强大的在线编辑器，让用户可以直接在上面修改，然后定稿。”
|
||
|
||
我记得有一次，我们为了Markdown转Word的一个脚注样式，在会议室里争论了两个小时，确保它在不同版本的Office软件里都不会错位。而与此同时，我们那个核心的纪要生成模块，还只是一段不到十行的、从网上抄来的通用提示词。
|
||
|
||
现在回想起来，那是一种令人后怕的“勤奋的懒惰”。我们一头扎进了确定性的舒适区，用战术上的忙碌，来掩盖战略上的迷茫。这就是软件工程师的惯性陷阱。
|
||
|
||
这个陷阱的根源在于，我们没有意识到，我们面对的游戏规则已经彻底改变。
|
||
|
||
在传统的软件开发世界里，我们是“建造者”。我们的任务是与确定性系统打交道，用一行行精确的代码，建造一根根绝对可靠、无泄漏的管道，确保数据能准确无误地从一端流向另一端。UI、格式转换、功能扩展，都是在这根坚固的管道上增加更方便的“阀门”和“仪表盘”。
|
||
|
||
然而，在AI开发的世界里，我们面对的是一个“概率性系统”。输入A，它可能输出B1、B2，甚至是糟糕的C。我们打交道的，不再是冰冷的逻辑，而是一个不完美的、模糊的、需要被引导的“数字心智”。我们的角色，必须从“建造者”，转变为“驯养师”或者“园丁”。我们的核心任务，不再是编写无懈可击的指令，而是如何通过沟通、约束和反馈，去“塑造”AI的行为，引导它在我们划定的框架内，做出最接近我们期望的创造。
|
||
|
||
可当时的我们，完全没有这个意识。我们用尽全力，为一个没有思想的机器人设计更帅气的盔甲，打磨更光亮的漆面，甚至为它的靴子该是什么材质而争论不休，却唯独忘了，它的内核空洞无物。我们是在为它“美颜”，却忘了先给它注入“灵魂”。
|
||
|
||
---
|
||
|
||
转折点来得既尴尬又必然。在一次内部评审会上，我们用一段销售团队的真实复盘会议录音进行测试。结果，智能体输出了一份“惨不忍睹”的纪要：它抓取了几个无关紧要的寒暄作为“关键讨论”，把一位同事的抱怨当成了“核心风险”，而真正关于策略调整的决策，却被淹没在流水账里，只字未提。
|
||
|
||
整个会议室一片沉默。那个我们精心打磨的、能完美导出PDF的界面，此刻看起来像一个精致的笑话。
|
||
|
||
正是这次代价高昂的失败，把我从“惯性陷阱”中猛地拽了出来。我意识到，我们过去引以为傲的核心能力，可能正是我们现在的最大障碍。在信息化和数字化的时代，我们之所以能成功，是因为我们极其擅长业务建模——我们可以精准地把一个线下的采购流程、审批流程，翻译成一套无懈可击的线上系统。
|
||
|
||
但在智能化时代，这远远不够。AI的原生能力是语言和模仿，它不缺完成任务的能力，缺的是判断力。因此，我们的工作必须升级到认知建模——将一个领域专家的思考方式、判断标准、甚至是直觉，翻译成AI可以理解和执行的框架。
|
||
|
||
我们暂停了所有关于UI和功能点的讨论，团队回到了最原始的原点。我要求大家像侦探一样，重新审问会议纪要智能体这个产品。我们问的不再是“要不要加PDF导出”，而是启动了一份源于我过往思考的“隐形清单”（参见[《从正确的废话到可行性幻觉》](https://sayings.wantsong.life/post/2025-07-09-correct-nonsense/)）：
|
||
|
||
* **第一问，它的“灵魂”是什么？（核心层）**
|
||
这个纪要最终是给谁看的？是给日理万机的CEO，让他一分钟内抓住核心决策？还是给健忘的项目经理，让他清晰地追溯每个任务的负责人？抑或是给未能参会的同事，让他们快速了解会议的全貌？我们最终将用户场景聚焦在“项目管理者”上，他的核心诉求是：**明确决策、梳理任务、追溯责任**。这个灵魂，决定了纪要的一切。
|
||
|
||
* **第二问，它的“能力边界”在哪？（执行层）**
|
||
基于上述灵魂，我们重新定义了一份“好”纪要的标准。它必须包含四个核心模块：**会议摘要、关键决策、待办事项列表、以及开放性议题**。我们设计了严格的JSON输出结构，每个待办事项都必须包含“内容”、“负责人”和“截止日期”三个字段。这为我们后续进行提示词工程和多智能体协作，提供了清晰的蓝图。
|
||
|
||
* **第三问，它的“刹车”在哪？（约束层）**
|
||
AI最可怕的是“一本正经地胡说八道”。我们如何约束它？我们设定了规则，比如，如果识别出的“待办事项”中缺少“负责人”或“截止日期”等关键元素，智能体不能臆测，而应将其归入“开放性议题”并提示用户补充。对于录音中可能涉及的个人隐私或敏感词汇，我们建立了过滤机制，确保AI不会在纪要中“大嘴巴”。
|
||
|
||
* **第四问，它“搞砸了”怎么办？（操作层）**
|
||
我们必须预设所有可能出错的环节。如果录音质量太差，语音识别的置信度低于某个阈值，系统应该直接拒绝处理并告知用户原因，而不是硬着头皮生成一堆乱码。如果AI分析后认为本次会议没有任何明确决策，它应该输出“本次会议未形成明确决策”，而不是为了交差而杜撰内容。
|
||
|
||
这个过程，就是“认知建模”。它枯燥、费力，远不如写一个新功能来得有成就感，但它第一次让我们感觉自己不再是机器的“美颜师”，而是它的“心智设计师”。我们正在为这个智能体注入灵魂、划定边界、定义行为。
|
||
|
||
---
|
||
|
||
认知建模如此重要，但一个严峻的问题摆在了面前：由谁来主导？让一群沉迷于代码优雅和系统性能的工程师，去定义抽象的“灵魂”和“边界”，这本身就是一种错配。
|
||
|
||
这次转型的阵痛，让我逐渐清晰地看到未来智能化团队的理想形态。它不再是单一工种的集合，而是一种全新的“二元协同”模式（参见[《AI时代的“新文艺复兴”：为什么未来属于文理兼修者》](https://sayings.wantsong.life/post/2025-06-14-contemporary-renaissance/)），需要两种角色紧密配合：
|
||
|
||
1. **AI应用架构师:**
|
||
这个角色，更像是具备“新文科生”思维的“业务/AI翻译官”。他们不一定精通算法，但必须深谙业务，擅长结构化思考和语言表达。他们负责进行“认知建模”，定义问题，设计AI的工作流和核心提示词。他们的产出，决定了AI应用**效果的上限**和**灵魂的深度**。他们确保AI“做对事”。
|
||
|
||
2. **技术赋能者:**
|
||
这就是我们这些传统的软件工程师。我们负责搭建和维护RAG系统、优化API接口、保障整个系统的安全、高效和稳定。我们的产出，决定了AI应用**质量的下限**和**运行的稳定性**。我们确保AI“把事做成”。
|
||
|
||
在我们的“会议纪要”项目中，我被迫扮演了前者的角色。我花大量时间去和销售、项目经理访谈，去理解他们到底需要一份怎样的纪要，然后将这些模糊的需求，转化为“隐形清单”上的条条框框，再设计出层层嵌套的提示词链。而我的团队，则发挥他们的专长，将这套复杂的逻辑，用最稳定、高效的工程架构实现出来。
|
||
|
||
我们开始有了全新的分工协作。他们会挑战我的提示词设计：“你这个判断逻辑太模糊，在极端情况下可能会导致token浪费。”我也会反驳他们的技术方案：“这个RAG的知识库切片方式太粗暴，会丢失上下文，导致AI无法理解决策的背景。”
|
||
|
||
这种“文理兼修”的碰撞，让我们的产品发生了质变。我们不再是各说各话，而是围绕着“如何让AI更聪明地解决问题”这个共同目标，形成了一个有机的整体。
|
||
|
||
---
|
||
|
||
现在，我可以回答我朋友最初那个“冒犯”的问题了。
|
||
|
||
我们的会议纪要之所以看起来“不像AI生成的”，不是因为我们事后用“人”去加工了结果，而是因为我们事前用“人的思考框架”去设计、塑造、乃至“驯化”了AI。我们不再是内容的搬运工，而是认知的架构师。
|
||
|
||
这段经历，让我对AI时代的转型之路有了更清醒的认识。对绝大多数像我们这样的公司和开发者而言，我们的使命不是去“造锤子”（基础大模型），那是科技巨头的战场。我们的机会，在于成为一个更优秀的“工匠”，用好这些日益强大的锤子。
|
||
|
||
而要把AI这把新锤子用好，关键不在于锤子本身有多重，而在于挥舞它的工匠，是否深刻理解自己要创造什么。它需要的，是一种超越代码的智慧——一种为技术注入认知、为系统注入灵魂的能力。
|
||
|
||
所以，如果你也和我一样，是从软件工程师的阵营，迈向AI开发的新世界，那么请务必记住我们扔掉的第一件东西——确定性。拥抱概率，从建造者转变为驯养师，主动地去思考、设计和塑造你的AI。因为在这片新大陆上，最稀缺的，永远不是更快的机器，而是更懂人心的灵魂。
|