docs(retrospective): add project growth writeup

agent-project-sharing-speech.md

@@ -0,0 +1,134 @@
+# Agent 项目经验分享演讲稿
+
+## 第 1 页：标题页
+
+大家好，今天我想分享的是我们第一次做 Agent 项目时的一些真实经历。
+我想讲的不是我们项目做得有多成功，而是我们从 0 到 1 推这个项目的时候，踩过哪些坑、做对了哪些事情，以及这些经历让我自己学到了什么。
+
+因为我觉得，第一次做这种项目，最有价值的往往不是最后做出来多少功能，而是中间那些会反复出错、但也最能让人成长的地方。
+
+我自己在这个项目里主要负责前端相关工作，但做到后面我发现，如果只盯着前端实现，其实很难真正把项目看明白。所以这次分享其实也是我自己从主要关注前端，到慢慢开始理解产品、协作和架构的一个过程。
+
+## 第 2 页：我们做的是什么项目
+
+在正式开始分享之前，我先简单介绍一下我们做的项目。
+
+我们做的是一个前后端分离的本地 Agent 桌面协作系统。
+前端主要负责悬浮球、仪表盘、控制面板这些交互入口和结果承接；后端主要负责任务编排、模型与工具执行、风险治理和正式结果交付。
+
+之所以要做前后端分离，是因为这个项目不只是一个页面应用，它同时还涉及本地任务执行、状态管理和治理链路，所以前后端职责需要分开。
+前端分离出去，不只是因为页面要单独开发，更重要的是后端承载的是任务编排和执行主链，它需要作为一个相对独立的本地服务存在。
+
+同时，它和普通聊天框式 AI 不太一样。我们希望它围绕桌面现场去承接任务，比如用户可以通过悬浮球、文本选中、文件拖拽这些方式发起任务。
+简单来说，我们想做的不是一个只会聊天的 AI，而是一个能真正协助用户完成任务的 Agent。
+
+## 第 3 页：项目从 0 到 1 的基本流程
+
+在正式进入项目细节之前，我想先用一页简单说一下，一个项目从 0 到 1 大致会经历哪些阶段。
+
+一般来说，首先是需求确认和立项，然后进入整体设计和技术调研，再进入正式开发。开发过程中不会是完全闷头写代码，而是会不断和上下游做阶段性对齐。后面再进入测试和联调，确认整体功能和接口都能跑通之后，再部署上线。上线之后，其实也不是结束，而是进入持续迭代和优化。
+
+我觉得这次项目也让我更明显地意识到，开发只是其中一个阶段，前面的设计和后面的联调、测试、部署，其实都很重要。
+
+## 第 4 页：最开始，我们只是想先把 Agent 搓出来
+
+我们最开始做这个项目的时候，其实目标很简单，就是想先做一个类 OpenClaw 的通用 Agent，把我们觉得有意思、觉得能做的功能都先搓出来。
+
+那个时候我们没有特别完整地去想市场、产品定位或者需求边界，更多是一种“先做出来再说”的状态。大家的推进方式也比较直接，就是想到什么就加什么，希望让这个 Agent 变得更强、覆盖更多场景。
+
+现在回过头看，这种阶段其实很正常，因为一开始大家通常都是靠激情和想法在推项目。但问题也很明显，就是如果没有一个比较清晰的主线，功能越加越多之后，团队很容易就会慢慢失去边界，最后变成一直很忙，但不一定越来越接近真正想做的东西。
+
+## 第 5 页：第一个转折，先停下来做市场和产品定位
+
+我觉得第一个比较关键的转折点是在第二周。
+
+那个时候我自己已经开始很明显地感觉到，项目不能继续只靠堆功能往前走了，所以我主动去推动大家做市场调研，重新确认我们的产品定位，并把竞品、市场资料、技术栈这些内容整理出来。
+
+更重要的是，我们开始重新看最开始提的那些功能想法，不再默认“都要做”，而是开始做筛选和删减，把真正符合产品方向的部分留下来，把一些不必要或者不够核心的先拿掉。
+
+这个过程让我第一次真正理解了“少就是多”这句话。以前会觉得做得越多越厉害，但后来我发现，一个项目真正重要的，不是功能堆得多满，而是主线是不是清楚，重点是不是明确。
+
+## 第 6 页：前期文档让项目开始稳定推进
+
+后面我越来越明显地感受到，真正让项目开始稳定推进下来的，其实不是某一个具体功能，而是前期文档慢慢补起来了。
+
+这里面包括产品定义文档、市场调研文档、PRD，还有技术栈整理。
+因为在这些文档没有成型之前，团队其实很容易陷入一种“走一步想一步”的状态。今天想到一个方向就做，明天发现另一个问题再补，整个推进方式会比较散。
+
+但是有了这些文档之后，团队至少开始有了一个相对一致的目标，也有了比较明确的推进依据。对我来说，这也是我第一次真正体会到，文档不是形式，而是协作和推进的基础工具。
+
+## 第 7 页：一个重要启发，先做原型，再反推 PRD
+
+不过在这个过程中，我还有一个印象特别深的收获，就是导师给我们的一个方法上的启发。
+
+导师提出的一个想法是，在 AI Coding 的模式下，不一定非要完全按照传统产品流程，先把 PRD 写得很完整，再开始做产品。
+有时候也可以先快速做出原型，再反过来推 PRD。
+
+我觉得这个思路对我们很有启发，因为它让我们没有完全照着当时已有产品的路径走，而是敢于尝试一种不同的形态。
+
+比如我们后来没有采用很常见的聊天框式交互，而是把很多操作收在悬浮球上，希望把 Agent 做成一种更贴近操作系统、更自然融入用户环境的存在。
+
+虽然最后这个方向我们没有实现到特别理想的程度，但这个尝试本身让我开始意识到，产品设计不一定只是跟随现有范式，也可以通过原型先试出一种新的交互形态，再回过头去定义需求和产品逻辑。
+
+对我来说，这种思考方式其实也是一个很大的进步。
+
+## 第 8 页：踩得最深的坑，前后端对齐不充分
+
+如果说这次项目里我觉得踩得最深的坑是什么，那一定是前后端对齐不充分。
+
+我们当时的一个问题是，很多协议和交互理解主要集中在少数前后端同学那里推进，其他同学并没有充分参与。结果就是，虽然文档写出来了，但它并没有完整覆盖所有人的理解和需求。
+
+这个问题在正式开发以后就慢慢暴露出来了。大家开始不断发现，有些字段不完整，有些交互场景根本没提前考虑到，于是后面就开始不断补文档、改逻辑、返工。
+
+这件事给我的感受特别深，因为它让我非常明确地意识到，前后端协作里最重要的不是“各自把自己的部分做完”，而是要尽早把语义和边界对齐。
+因为一旦前期理解没有统一，后面返工成本会非常高。
+
+## 第 9 页：开发阶段，我们逐渐形成了 GitHub 协作方式
+
+到正式开发阶段之后，我们后面也逐渐形成了一套更工程化的 GitHub 协作方式。
+
+最开始我们其实用过飞书，但后来发现，在开发阶段大家已经不只是需要共同编辑文档了，更需要一种能把任务、问题和代码修改真正关联起来的协作方式，所以 GitHub 对我们来说会更合适。
+
+我们后面的方式大致是这样：先在 Project 里看整体任务推进，再把发现的问题或者需求拆成 Issue，然后针对具体 Issue 建分支开发，开发完成之后提 PR，在 PR 里看 diff、讨论实现、做 review，最后再合并继续推进。
+
+这种方式带来的好处很明显。第一，任务和问题更可追踪；第二，分工更清晰；第三，后面回头看时，能知道某个问题是怎么被提出、怎么被修改、怎么被解决的。
+
+同时我也越来越能理解，开发过程中不能闷头写代码，每完成一部分都应该和上下游继续对齐方向，发现问题及时调整。
+
+## 第 10 页：架构和开发现实
+
+这一页我最想讲的是，开发不是“边做边优化架构”这么简单。
+
+现实里往往是主链要先跑起来，很多复杂度是在开发后期才真正暴露出来的。
+我们项目后期虽然也拆过 orchestrator，把原来的大文件拆成了很多小文件，但我现在回头看，会觉得这种拆分更多是缓解了可读性问题，而不等于真正完成了架构重构。
+
+因为真正难的不是把文件拆小，而是明确职责边界，也就是哪些逻辑应该留在编排层，哪些应该下沉到治理层、运行态层或者交付层。
+
+所以我后来会觉得，架构不能完全按照我们一开始想象的那种方式，一边沿着主链开发、一边自然扩展出来。
+更现实的做法其实是，先把主链和主要扩展方向尽量走出来，把大的职责边界先看清楚，再回到具体开发里，根据真正暴露出来的细节问题继续调整。
+
+也就是说，架构优化不是边写边顺手就能完成的，它往往需要先把主链跑通、把边界看清，再在后续开发中不断修正细节。
+
+## 第 11 页：我自己的成长，从前端执行到开始理解全局
+
+如果要说我自己在这个项目里最大的成长，我觉得不是我写了多少功能，而是我开始慢慢从一个主要关注前端实现的人，走向了一个开始理解项目全局的人。
+
+一开始我主要盯的是页面、交互和功能怎么接起来，但做到后面，我开始越来越关心另外一些问题，比如产品定位是不是清晰，需求有没有收敛，文档有没有对齐，前后端理解是不是一致，架构的主链到底是怎么跑的。
+
+我后来也越来越明显地感觉到，在 AI Coding 这种项目里，不能只把自己看成一个“只做前端的人”。因为很多时候，真正决定项目能不能推进的，不只是某一层写得好不好，而是整条主链是不是成立，协作是不是对齐。
+
+所以这次项目对我来说最大的成长，就是我开始主动从实现层往上看，去理解产品、协作和架构，而不是只停留在页面和功能本身。
+
+## 第 12 页：最后的结论
+
+最后如果要总结这次经历，我觉得我最想说的有五点。
+
+第一，功能堆叠不等于产品成立。
+第二，文档不是形式，而是协作基础。
+第三，前后端对齐会直接决定后期返工成本。
+第四，架构优化的关键，不是先拆文件，而是先明确职责边界，再围绕主链逐步拆分模块。
+第五，做 AI 项目时，必须慢慢从局部实现走向主链理解。
+
+对我个人来说，这次项目带给我的最重要的收获，不只是学会了某个功能怎么做，而是我开始理解，一个项目是怎么从想法、定位、文档、协作，到真正开发和落地，一步一步推进起来的。
+
+我觉得这也是这次分享里最想和大家交流的部分。