不再洄游，而是深潜 & grillme之产品经验谈

洄游#

带着这个问题，这段时间我保持高强度的网络冲浪，并尝试进行从需求设计开始，架构，spec驱动开发，部署上线······ 常常是，前一个项目还未结束，新的灵感又向我涌来，每一次设计的时候都会觉得上一次的设计架构很烂，我的实现方式是否对我想提高效率的过程产生了负担？甚至质疑这个需求是否真实存在。

追星赶月之中，我慢慢摸清楚了我在做一件怎样的事情：我不是艺术家，如林纳斯般天才铸造出如诗般的Linux OS Kernel，我也无需成为Geek大师，在AI时代用简洁高效的代码以及深入的内核理解嘲笑AI的无能。

我是一位产品与解决方案的提供者，用户雇佣我是因为他们需要一份非本职的趁手工具，而并不希望投入过多时间，于是向我购买技术服务。广义来说，我们是个性化的铲子工匠，我们所赚取的是一套壁垒差与技术债。

所以我们这一行的商业行为便是从客户需求出发：客户需要一个怎样的解决方案，是我们的上游，不管是2B的OA还是2C的APP小程序，本质上是定制化销售，过去我们给予了项目经理的角色，中间就是tech-header与PA-SM，这一层是产品与front的设计与需求和业务的拆解以及配套需求的架构选型与技术解决方案的框架搭建。最末端—也就是传统开发工程师了，他们是耗材，是供给侧的末端的流动力工。

在产品之旅中，我曾将技术选型&架构和需求设计模糊过，导致画出的需求图不伦不类。产品需求包括整体工作loop的设计与各个功能和模块之间的逻辑联系，怎样更有taste?更能抓住用户的心？以及如何让用户的留存界限尽量在体验核心和功能后，这样可以更直观优化与迭代产品。

而tech做的架构部分和解决方案则是在领域结构上尽可能更高效，这里需要考虑高并发的节点梳理和服务器负载均衡，让成本尽量低并且可以胜任业务需求，为用户保障较好的观感。

想通了这些，我开始回头梳理自己走过的路：最开始是HTTPS、TFTP等网络协议相关的造轮子，后来做领域模块设计和团队协作，再后来尝试把LLM当作队友，由自己担任PO，设计产品、编写spec，分配子bot协作完成loop engine的开发。此外，我还尝试过单片机、micro-ROS与Qt、Linux C的综合开发。看起来很杂，很乱，但这些尝试也让我逐渐看清了自己在开发中漏掉的东西。

中途有一段时间，我甚至主动屏蔽代码层，把实现交给AI，自己聚焦界面与设计。等到真正发现问题，才意识到底下的约束和逻辑已经成了黑箱，难以理清，死代码也积了不少。页面看得见、功能点得动，并不代表我还掌握着这个系统。

我的第一反应是spec写得不够明确。但继续追下去，我发现问题经常集中在模块交接的地方：单独看，每个模块似乎都完成了自己的功能，组合起来却没有对齐。同一份数据，上下游是否按同一种含义处理？一个模块认为已经完成的事，是否真的满足下一个模块继续执行的条件？这些我们觉得理所当然的隐含关系，并不会因为功能被拆开、任务被分配出去，就自动得到遵守。于是，局部都说得通的实现，最后仍然可能堆成屎山。

这也让我重新理解了“spec不够明确”：**只把每个模块要做什么写清楚还不够，模块之间共同遵守的业务规则、交接条件和异常处理，也需要明确，并在实现时核对。**否则，写得再细的局部要求，也未必能拼成一条正确的完整流程。

测试同样会掉进这个坑。冒烟测试能检查基本流程是否跑通，却不能据此认定业务逻辑正确。如果AI顺着已经写好的实现来生成测试，就可能把实现里的误解一并当成预期结果。哪怕写出2000多个测试，也可能只是在反复确认“代码确实这样运行”，而没有回答“业务是否应该这样运行”。所以才会出现测试一片绿，亲自体验时却发现逻辑匪夷所思的情况。

于是，我现在每次提交前都会认真看diff，重点核对改动有没有遵守原本的业务约定，尤其留意模块之间的衔接，而不只是看单个函数有没有写对。测试通过是检查的一部分，但不能替我判断这些约定是否成立。那些我们以为AI自然会连起来的关系，恰恰需要自己多看一眼。

深潜#

在尝试过这么多的领域之后，我的周游列国之旅是时候结束了。前中期我关心web全栈开发，这是软体的起点，直到我发现瓶颈是人的attention,那么是否我们真的需要这么多软件？作为有可靠验证集的AI Coding ，成长飞速。我做的纯软体的东西，别人也可以做，也许毕业后我只是比别人多学了一两年，多使用了一两个中间件，多做了几个app一样，一个有想法和创意的非本专业学生在如此强大的模型加持下，做出来的软体远胜于我。因为在这个关系中，我的角色仍然是补偿层，可是“足够强大”模型其实不需要这个。这就是没有构造很强的壁垒的后果。

那么偏硬件一点的嵌入式呢？嵌软在一定程度上面临与纯软一样的境地，相比而言，嵌入式的可发挥空间更小，这是一门“节约的艺术”。那么这也注定了代码量不会多，不需要很复杂的权衡和软件工程设计。那么在挂载官方的mcp与skill等Tools，开发更简单了，芯片手册天然适配渐进式披露的工程架构。

难道就没有路了吗？我看未必——技术的角色正在转型。市场对我们的要求从会单一简单的技术与解决方案转向了跨领域交叉的赋能。换句话说：AI让入行门槛变高了。正如我以往的观点，我们从构建者转向组织者与领导者。借助AI，我们可以快速学习前沿的领域，并且跨行业技术进行交叉汇聚，产出高阶的解决方案。这也是让赛博技工走向真正的工程师的路线。

于是，我将结合我的qt+micro ROS基础做减法，继续在机器人自动驾驶亦或者具身智能的交叉学科进行深耕。而进入此类领域，需要大量的知识储备与快速学习能力——这也是为什么我多次强调框架学习与快速学习的重要性。而这些学习不是做理论，而是为技术方案的解决服务。没有崇高的知识灵魂而是充满泥泞的调校与试验。

这里有一个误区，就是买开发板依照生态来学。这是两套叙事，因为厂商的生态是为了加强它的壁垒，而作为一个产品，重要的是让这些散件组装和调教，尽可能满足客户需求，在某种情况下他们是矛盾的。你学的不专，不精，在生态上做的任何都像是在做labs里的试验，慢慢摸清原理但是很杂，没有一个具体的服务场景，这时候你就会对未来感到迷茫与焦虑，因为知识是学不完的，热点是追不完的。

现在我们能做到的是，在我们自身的领域里，把一件事尽可能做的尽善尽美。向深处挖，向前沿推进。

**这里的深潜，需要把厂家的NPU的优劣逼出来。**厂家卖板子，其实是在卖第一阶段的集成解决方案，封装底层能力，让我们可以更快落地。但跑通官方demo，只能说明它在厂家给定的条件下可以工作；放进自己的业务，模型能不能部署，哪些算子支持得好，精度、延迟、功耗表现怎样，数据搬运和前后处理会不会反而成为瓶颈，这些都需要在实际任务中调校与试验。

所以我说的理解原理，也要围绕这些问题展开，不必一路钻到驱动层。我要知道这块NPU擅长什么、不擅长什么，宣传的能力在什么条件下成立，遇到限制时能不能绕开，绕开的代价又有多大。把这些边界摸清楚，才能判断下一次业务该不该选它，以及怎样让它和其他散件配合。这才是我想积累的东西：从跑通一个生态里的示例，走到对一套技术方案的优劣心里有数。

grillme之产品经验谈#

grillme是github上skills集中的一个skill，它用很轻量的形式解决了一个很多开发者都有的痛点——**还没想清楚，就已经开始做了。**它通过反问，让开发者在回答中再次深入思考产品与技术，把模糊的想法、默认的前提和没有想过的代价逐渐摊开，想清楚再决定。

如果让我来做这种辅助，第一反应可能是做一个简单app，挂在环境里，监听你正在做什么，再判断什么时候应该提醒、什么时候应该追问。但这样一来，为了找到值得介入的那个时刻，就要持续接收大量无关信息，噪声很大；环境里又多了一套常驻软件，占资源、拖慢电脑，还要处理监听和维护的问题。想帮助用户思考，最后却先给用户增加了一层负担。

而grillme直接依附已有的生态，把能力做成skill，借用现成的对话和上下文，在需要的时候进入追问。它很轻，却能把这件事做得很好。它让我看到，产品的分量不一定来自自己搭了多少东西，也可以来自找准一个痛点，用很小的改动让已有工具变得更有用。这就是我说的大道至简。

再往另一端看，原子化、低耦合也是有道理的工程做法：把职责拆清楚，限制每一步的权限和影响范围，让模型的行为更加安全、可控。但这不意味着所有事情都要拆成最小的原子，每一层都包上一套独立机制。拆得越细，接口、调用、上下文传递和维护的成本也越多，最后可能花了很多资源，只换来很小的收益。

**我们需要一定程度的原子化，但不是全部。**真正要权衡的是，哪些边界必须用工程手段守住，哪些能力可以依附已有生态，哪些地方用一个简单的skill就已经足够。该有的保障不能省，也不必为了形式上的完整把整个过程越做越重。**简单有效是第一性原则，工程化的程度应当服务于它。**这也是为什么我说，软件工程是一门“权衡的艺术”。