分享技术见解、生活感悟和成长历程
前段时间，一位白帽子在对我们的系统做渗透测试时，不小心把单点登录系统里所有业务系统的注册数据全部删除了，导致我们所有业务系统都登录不了了。 开始是我自己排查的，我发现线上有一个 JS 加载报错了，以为是 JS 报错导致后续逻辑没有执行（因为后端服务没有任何报错）。我看这个 JS 是引用的三方 CDN 的资源，而且是一个统计类的 JS，所以就直接把它删了。 结果还是不行。 最后，还是借助 AI 解决的。在让 AI 分析问题的时候，它通过我们的日志服务发现当天早上有一个异常的请求，这个请求会删除线上系统的注册数据。 然后，AI 根据代码逻辑又给我生成了一个修复数据的 SQL，执行完，果然就恢复了。
终于，又完成了一个人生目标——“克服驼背”。 这也是我完成的第15个人生目标。 这个目标惦记了很多年，也尝试过不少办法，没想到最后帮上忙的，竟然是骑摩托。 27年坐出来的习惯 先说一下，我所说的“驼背”，其实主要是含胸。按我自己的理解，就是一个习惯性的姿势问题。 从小学开始，我大部分时间都是坐着的。上学16年，工作11年，加起来27年，这期间80%以上的时间都是坐在椅子上的。 加上我自己四肢有点懒惰，不爱运动，坐着坐着就想蜷缩在一起，让自己更舒服一点。时间久了，就变成“驼背”了。 我大概高中时就意识到自己有点驼背，只是那时候不严重，也没太当回事。 但是毕业之后，体重一度从140斤涨到200斤，
我姐姐是一名老师，有将近200个学生。 她每天要在好几个微信群里收集家长发来的作业图片，一张一张保存，再一个一个核对谁还没交。收完之后，在手机相册里批改，改好了，再把结果发给对应的家长。 我光是想想就觉得头大。将近200个学生，作业、图片、家长，要一个个对应起来，本身就是一件很繁琐、也很容易出错的事。 所以她一直跟我说，想让我给她做一个系统，让学生交作业、她批改作业都能简单一点。 前段时间，我去了我姐家，又聊到了这个事。我就一边和她聊天，一边把需求记下来。也是因为好久没见了，我们聊了很多东西，一直聊到将近凌晨2点。 最后，我把记下来的需求整理好，提交给了AI，让它自己实现、自己验收，再给我生成
前段时间，我们一个设计同学突然找到我，说他做了一套系统，想让我帮忙部署一下。 我当时真的有点震惊。 一个做运营素材的设计同学，居然已经能自己做出一套系统了？ 我先没有答应部署，而是让他把系统从头到尾讲了一遍。听完以后，我发现它并不是随便拼出来的 Demo，里面已经有了不少完整的业务思考。 这个系统，做得还挺好 这个同学属于 UI 设计组，平时主要负责运营素材设计。他做这套系统，也是从自己每天面对的问题出发的，系统主要包含3部分内容吧。 第一部分是需求管理。 业务提出的设计需求，可以统一进入系统，在里面流转和处理。需求完成以后，对应的素材也会被汇总起来，所以它同时还有一个素材中心的功能，方便后续
最近一个月，团队在 AI Coding 上又往前走了一段。 如果只看表面，我们做的事情还是那些：用 AI 写 PRD、查业务、出方案、改代码，再想办法把整套流程搬到云端。可越往下做，我越发现问题早就不只是“模型能不能写代码”了。 我们开始面对两个更难的问题。 一个是，怎么把人的业务知识变成 AI 可以长期使用、团队也可以持续维护的工程资产。另一个是，怎么在 AI 的自由和传统软件的确定性之间，找到一个可以长期运行的平衡。 这两个问题，刚好对应了最近一个月 PRD skill 和 Zeus Talos 的两次变化。 第一版PRD Skill，先解决了信息差 最开始做 PRD skill 时，我们
前几天，团队有人给我提了个 skill 的变更。 我盯着看了半天。 逻辑写得很细，挑不出什么毛病。当我想要点击合并的那一刻，心里有个声音：这条优化，到底有没有用，我说不清了。 😅 以前不是这样的。 9 个 skill 的简单日子 我刚搞这个工作流那会儿，一共 9 个 skill，对应 9 个关键研发节点。 那时候加东西很简单。没有现成的内容，谁想往 skill 里塞一段逻辑，直接写进去就行。也不需要评估——那时候是"有"和"没有"的区别。从 0 到 1，加进去就一定有用，谁都看得见。 后来 skill 从 9 个变成了 69 个。 数量多了是一方面，更要
最近这几天，我又开始焦虑了。 原因是，我突然意识到一件事。 已经有一阵子，没人反馈 Zeus 的问题了。 Zeus 是我们团队做的一套 AI Coding 工具体系。 说白了，就是想让 AI 把"写代码"这件事，从头到尾接过去。 用了两个多月，大家从一开始的别扭、吐槽、不信任，慢慢变成了—— 用得挺顺。 顺到，没人抱怨了。 按理说，这是天大的好事。 可那一刻，我心里咯噔一下。 因为"没人提问题"，有两种可能：一种是真的没问题了，另一种是，大家已经看不见问题了。 我估计，是后者。 浮在水面上的，是看得见的成绩 这半年，团队是真的变样了。 Zeus、Zeus
今天又是给女儿改卷子的一天。 两页卷子，错了6道题。 最后那两道，她改了5遍，才改对。 最难受的是，那些题她其实都会。就是算不对。改一遍，对个一两道，再改，再对一两道，磨磨蹭蹭，一直到第5遍。 她改的时候，嘟着嘴，流着泪。 我坐在旁边，心里又气又无奈。😮💨 气的不是她笨，是她明明会，却就是静不下心来算对。无奈的是，我好像也帮不上什么忙，只能看着她一遍一遍地改。 好在我们关系还不算差。她虽然一百个不愿意，但还是嘟着嘴、抹着眼泪，把卷子做完了。 可看着她那个样子，我忽然开始想：问题，是不是出在我身上？ 我以为我只是"认真"，可她看到的是"严肃" 我发现，我
最近 Loop Engineering 在持续刷屏。 公众号在刷，各种群里在讨论，我也看了好几篇文章。 每篇都有道理——五个组件、目标定义、古德哈特定律，逻辑很清晰，我都信了。 但看完之后有点空。 我的工作流该怎么 Loop 化？从哪起手？搭出来以后长什么样？ 没一篇说清楚。 所以想聊聊我自己的理解，以及我们实际在做的事——我们团队搭了个叫 Talos 的系统，算是目前我见过最接近"生产级 Loop Engineering"的垂类实践。 Loop 其实只有两种形态 在我看来，Loop Engineering 这件事，放长了看只有两个终点。 第一个是通用智能 AI。 它足够强
前面几篇，聊了团队怎么搭 AI 工作流、怎么建知识库。 今天聊聊 AI 在 PRD 编写和质量保障上，我们做了些什么。 其实这块从一开始就在工作流里。只是在开始的MVP版本里，核心全压在开发环节。 等大家真用起来，一个问题立马浮出水面： PRD 质量一般，工作流出来的技术方案，质量自然也上不去。 道理特别朴素：垃圾进，垃圾出。 源头的 PRD 含糊，后面 AI 再能干，也只是替你把这份含糊"发扬光大"。 所以我决定还是要治理一下这个源头。 第一步：先给 PRD 做个体检 我做的第一件事，是一个 PRD 质量检测 skill。 注意，它不碰业务逻辑，只做"规范层&q