如何把公司文档里的经验,变成自己项目里的工程约束
之前我调研过一个同类的二次开发项目。一开始我的想法很直接:把它的源码和文档找出来,看看他们怎么做的,哪些架构可以照着用,哪些功能可以直接参考。
之前我调研过一个同类的二次开发项目。一开始我的想法很直接:把它的源码和文档找出来,看看他们怎么做的,哪些架构可以照着用,哪些功能可以直接参考。
最近在重新拆 AI 视频项目的任务,有两件事让我停下来想一个更基础的问题:我们到底在做什么。
最近我在尝试把一批开发需求交给多个 AI 执行。这批需求的一部分来自会议录音转写:里面有产品边界、技术方案、人员分工,也有口误、同音字和讨论到一半又被推翻的想法。最直接的做法是把转写总结成任务列表喂给 AI,等它写完再补测试和自测。
最近在规划一个基于开源 Agent Runtime 的桌面客户端,UI 开发很快遇到一个具体问题:到底要不要引入第三方组件库?是用 MUI、Ant Design 快速搭页面,还是所有组件都自己写?
周末我做了一件事:把自己 GitHub 上的 32 个私人项目,逐个过了一遍,判断哪些适合开源。结论是,一个都不能直接发。
最近我用一套自己常用的开发套路,从零交付了一个个人项目 Evolution OS(人生进化系统)。整个过程跑下来比较顺。这套流程我觉得可以作为后续做个人新项目的标准套路,这里做个记录。
最近我在思考一个比较现实的问题:团队使用 AI 工具之后,开发效率确实提高了,但是需求并没有跟着变多。
过去一年,很多人对 AI coding 的理解还停留在“让 AI 帮我写代码”。但是拉开差距的地方,已经不在于一次提示词写得多漂亮,而在于能不能把反复发生的工作、隐性的判断经验、验证规则、学习循环攒成可复用的 AI 基建。
在讲框架之前,先想清楚一个问题:领导坐在台下,他到底想听什么?
按此标准,博客中约 5%(~60 篇) 有 Skill 价值,其中真正高价值、可直接抽取的约 15-20 个。