离开社区的这两年，我以为自己不需要它了
离开社区的这两年，我以为自己不需要它了
有些事情，离开久了之后，会以为自己已经不需要了。
比如技术社区。
不是突然不喜欢了，也不是觉得它没有价值了。很多事情的离开，都不是一个郑重其事的决定。它更像是生活里一连串小小的让步。
这个月项目忙一点，活动就先不去了。
下个月客户那边有事，文章就先不写了。
再后来，公司、产品、团队、交付、客户、老系统、新需求，一件一件排在前面。社区没有消失，只是慢慢往后退。
退到最后，就变成了一种很自然的沉默。
人很容易适应这种沉默。
一开始还会觉得少了点什么，后来也就习惯了。甚至会给自己找一个很合理的解释：现在要做的事情太多，社区活动以后有时间再说。
但“以后”这个词，常常没有具体日期。
所以一晃，就是两年。
这两年，我更多是在项目里和问题打交道
这两年，我并不是不学习，也不是不思考技术。恰恰相反，我比以前更深地扎进了真实项目里。
真实项目没有舞台灯，也没有掌声。
它有客户反馈，有临时需求，有老代码，有权限，有状态，有导入导出，有页面细节，有报表口径，有线上问题，还有那些你知道迟早要还、但总是被更急的事情挤掉的工程债。
很多关于 AI、Agent、工程化的想法，也是在这些地方慢慢长出来的。
只是这些东西一直留在项目里，留在文档里，留在一次次复盘里。它们没有被拿到一个公共空间里讲，也就慢慢变成了只有自己知道的经验。
所以这次参加腾讯云架构师技术同盟在成都的城市沙龙，对我来说还挺特别的。
不是因为这场活动有多隆重，而是我确实隔了很久，又重新坐回了技术社区的现场。
我这次想讲的，不是 AI 工具清单
这次活动的主题是：
大模型到 AI 同事：Agent 时代的工程化落地。
我分享的题目是：
《一套自动化 Skill 的失败启示录与工程化重构》
这个题目听起来比较技术，里面有 Agent、Skill、MCP、TDD、研发工程化这些内容。
如果单独看这些词，很容易觉得这是一场讲工具的分享。
但我自己准备这场分享的时候，并不是想讲“我用了哪些 AI 工具”，也不是想讲“现在 AI 写代码有多强”。
我更想讲的是：一个小团队在真实业务系统里用 AI 的时候，到底发生了什么。
不是演示环境里的一次成功生成。
不是一句“AI 帮我写完了代码”。
也不是把所有流程接起来之后，想象中那个全自动、无人值守、一路从需求跑到上线的美好画面。
我想讲的是更具体的东西。
AI 确实能帮忙。
它能整理客户反馈，能读老代码，能写脚本，能补页面，能生成文档，能协助测试，也能把很多过去因为“不够紧急”而长期拖着的工程债往前推一截。
但它也会把一些问题暴露得更快。
如果任务边界不清楚，它会很快写偏。
如果文档太多但没有当前真源，它会在上下文里迷路。
如果一个小问题默认进入很长的流程，团队会被流程本身拖住。
如果大家只相信“已完成”三个字，而不去看测试、截图、PR、验收证据，那么 AI 写得越快，风险也可能累积得越快。
所以我这次分享里最想表达的，其实只有一句话：
不要焦虑 AI 替代，而要学会管理 AI 任务流。
这句话听起来没有“全自动研发”那么漂亮。
但它更接近我现在看到的真实情况。
AI 变强之后，人的价值不是消失了，而是变得更难偷懒了。
你要判断目标、边界和优先级，也要判断什么事情可以交给 AI 执行，什么事情必须由人来决定。
你还要判断，AI 给出的完成，到底是一个说法，还是一个可以被复查的结果。
这件事不性感。
但它很重要。
现场的问题，比准备好的答案更有意思
活动结束后，有一个场景让我印象很深。
大家没有马上散。
很多人围过来继续聊，问 Agent 怎么落地，问中小团队怎么用 AI，问 Prompt、Spec、TDD、MCP、Skills 这些东西怎么放进真实研发流程里。
我和赵老师、王老师被围在人群里，一时半会儿走不开。
那一刻我突然想起很多年前参加社区活动的感觉。
技术社区最有意思的地方，从来不是台上的人把答案讲完。
而是台下的人听完之后，继续追问。
“那真实项目里怎么办？”
“团队人少怎么办？”
“客户一直改怎么办？”
“这套东西放到我的项目里，会不会又变成负担？”
“如果 AI 真的能写代码了，那工程师到底应该把精力放在哪里？”
这些问题不漂亮，但真实。
技术讨论一旦变真实，就会从概念传播变成经验交换。
人和人之间，也会从“讲师”和“听众”，变成一群都在现场干活的人。
这是我很久没有感受到的东西。
过去两年，我更多是在项目里和问题打交道。项目不会鼓掌，也不会给你反馈表。它只会用另一种方式提醒你：这个方案不行，这个流程太重，这个文档没人看，这个页面客户还是不满意。
时间久了，人会变得很实用。
实用当然是好事。
但太实用之后，也容易忘记，很多经验如果不说出来，就只会停留在自己的项目里。它帮不了别人，也很难被别人校正。
做社区这件事，看起来简单，其实很耗人
王老师昨天跟我聊了不少。
他说这次活动的现场反馈很好，也提到成都这边的技术社区，还是应该继续做起来。
我听的时候有点感慨。
因为做社区这件事，外面看起来是办一场活动，发一个海报，找几个讲师，拉一个群，最后拍几张照片。
但真正做过的人都知道，它没有那么轻。
你要约人，要定主题，要找场地，要通知，要控场，要兜底，还要承受一种隐形的不确定性：
不知道大家会不会来。
不知道来了之后会不会认真听。
不知道听完之后会不会有反馈。
不知道下一次还能不能继续。
很多事情最后能发生，并不是因为它天然就会发生，而是因为有人愿意在背后把它一点点推起来。
这件事并不浪漫。
甚至很多时候很琐碎。
但社区就是靠这些琐碎的东西活下来的。
尤其是技术社区，它不是一次销售活动，也不是一个短期项目。很多时候靠的就是大家愿意多投入一点时间，把自己最近做过的事情拿出来讲。
如果没有人持续组织，这个事情就很容易冷下来。
所以我觉得，能有人愿意长期做这个事情，本身就很不容易。
真实经验，比标准答案更重要
赵老师昨天的分享和现场交流，也让我有触动。
我一直觉得，技术活动里最珍贵的不是“谁讲得更完整”，而是几个人在同一个现场，把各自真实经历过的问题摆出来。
有人讲模型，有人讲工程，有人讲组织，也有人讲自己踩过的坑。
这些内容未必都能立刻复用到另一个团队里。
但它会让人知道：原来不是只有我遇到这些问题。
这对技术人其实很重要。
很多时候，我们并不是缺一个标准答案。
我们缺的是一种确认。
确认自己正在面对的问题，不是孤例。
确认自己现在的困惑，不是因为自己太笨。
确认有些事情本来就很难，只是大家平时都把它包装得太轻松。
这也是现场交流和线上内容不太一样的地方。
线上文章可以很完整，很锋利，很有结论。
但线下交流里，人会暴露迟疑。
会说“这个我也还没完全想清楚”。
会说“我们当时这样做，后来发现不太对”。
会说“这件事在 Demo 里可以，但放到项目里就不一样”。
这些迟疑，反而让讨论更可信。
因为真实工作本来就是这样。
把个人经验拿出来，才可能变成公共经验
我过去写过《深入浅出 ASP.NET Core》，也做过一些社区分享。
那时候我以为自己主要是在分享技术。
现在回头看，技术当然重要，但更重要的是它背后的连接。
一本书、一场分享、一次活动，本质上都是把一个人的经验拿出来，放到公共空间里，让别人少走一点弯路，也让自己被别人重新校正。
后来我离开社区现场的这两年，其实并没有停止学习。
只是学习变得更私有了。
它发生在项目里，发生在客户现场，发生在凌晨改代码的时候，发生在一次次“这套流程看起来对，但为什么跑起来不对”的复盘里。
这些东西如果一直只留在自己电脑里，就会慢慢变成一种内耗。
讲出来之后，它才重新变成公共经验。
昨天对我来说，就是这样一个时刻。
我不是回来证明什么。
也不是回来宣布自己又要开始怎么样。
只是突然觉得，有些东西还是应该拿出来讲。
哪怕讲得不完美。
哪怕只是阶段性判断。
哪怕只是给别人提供一个反面案例。
社区的价值，可能就在这里。
它允许你带着还没完全想清楚的问题出现。
也允许你把真实踩过的坑，说给后来的人听。
AI 热闹背后，真实项目不会自动变简单
这两年，技术行业变化很快。
快到有时候让人来不及消化。
从大模型，到 Copilot，到 Agent，到各种 AI 编程工具，再到现在大家开始讨论 AI 同事、AI 工作流、AI 原生研发流程。
每隔一段时间，就会有一个新词出现。
每一个新词都像是在提醒你：你是不是又落后了？
但真实项目不会因为新词变多，就自动变简单。
客户不会因为你用了 Agent，就少提需求。
老系统不会因为你接了 MCP，就自动变清晰。
测试不会因为你写了 Prompt，就自己覆盖关键路径。
团队协作也不会因为你用了 AI，就自然变得更高效。
所以我现在越来越不喜欢单纯讨论“AI 会不会替代程序员”。
这个问题太大，也太容易让人陷入情绪。
我更关心的是：
AI 进入团队之后，我们怎么重新组织工作？
怎么把人的判断留在关键位置？
怎么让 AI 的执行能力真正变成团队能力，而不是个人炫技？
怎么让每一次生成、每一次修改、每一次提交，都有上下文、有证据、有回路？
这些问题没有那么热闹。
但它们决定 AI 能不能真正落地。
我在分享里说，AI 不是软件工程的替代品，而是软件工程水平的放大器。
现在我仍然这样认为。
如果一个团队本来就有清楚的领域语言、模块边界、测试反馈和协作流程，AI 会放大它的交付能力。
如果一个团队本来就很混乱，AI 也会放大这种混乱。
它不会自动让我们变得更工程化。
它只会更快地暴露我们原本没有处理好的问题。
这并不是坏事。
因为问题暴露出来，才有机会被处理。
重新坐回现场之后，我松了一口气
这次回到社区，我最大的感受不是热闹，而是松了一口气。
原来现场还在。
原来大家还愿意听。
原来那些真实项目里的笨问题、慢问题、脏问题，依然有人愿意认真讨论。
这比“AI 会不会替代程序员”有意思多了。
因为替代与否，很多时候是一个宏大叙事。
但真实工作里，我们每天面对的是更小的事情。
一个需求怎么拆。
一个页面怎么验。
一个 PR 怎么写清楚。
一个模块边界怎么守住。
一个团队怎么减少上下文损耗。
一个工程师怎么在 AI 变强之后，仍然保留自己的判断。
这些问题不一定适合做成十万加标题。
但它们适合坐在一个会议室里，和一群同样在做事的人慢慢聊。
社区就是由这些普通的事情组成的
两年没怎么参加社区活动，再回来，多少有点生疏。
但这种生疏也挺好。
它让人重新观察现场，重新看见人，重新感受到那些以前习以为常的东西。
比如有人认真听完一场分享。
比如活动结束后还围着继续问。
比如组织者在背后默默把事情撑起来。
比如一群并不一定熟悉的人，因为相似的问题坐到同一个会议室里。
这些东西听起来都很普通。
但社区就是由这些普通的东西组成的。
不是每一次活动都会改变什么。
但如果没有这些活动，很多人可能永远不会知道：原来还有一群人在想类似的问题。
这就够了。
最后，还是感谢
最后还是感谢腾讯云架构师技术同盟，也感谢各位提供后勤帮助的小伙伴。没有你们的支持，这场活动不会这么顺利地发生。
感谢王老师的组织和推动。
感谢赵老师以及现场几位嘉宾的分享。
也感谢活动结束后还留下来继续交流的朋友。
两年没怎么参加社区活动，重新回来，多少有点生疏。
但这种感觉还不错。
后面如果时间允许，我还是希望继续参与到社区里来。
不一定每次都讲一个很大的主题，也不一定每次都要给出什么完整答案。
把真实项目里的问题、踩过的坑、阶段性的判断讲清楚，我觉得就挺有价值了。