新闻资讯
别只会写提示词了!大厂AI项目模板曝光
这已经不是写提示词了。这些都是社区已经讨论了几个月的公开做法,并不是什么人偷出来的「内部模板」。message、写发布说明,这些都不该是每天手敲提示词的活,应该是skill调一下就出结果。message、写发布说明、修一类重复的bug,这些都该是skill,不该是每天手敲提示词。
不少人在为了能够用好AI编程,还在竭尽全力地研究提示词究竟该如何去撰写。然而,硅谷的一流团队已经证实,真正的效率源自于将AI嵌入到一套自动化系统当中,并非依赖更为聪明的“咒语”。


一个空项目五个月生成百万行代码

2025年,OpenAI的内部团队开展了一项实验,他们起始于一个空白的代码仓库,在大概5个月期间,借助Codex产出了约100万行代码,完成了约1500个代码合并请求,该团队起初仅有3人,之后扩充到7人,然而人工几乎并不直接编写代码。
作为带队工程师的Ryan,在后续的采访当中透露,这样一整套工作流,已然是快要接近那种“0人工代码、0人工审核”的极限状况了。他们所秉持的核心思路,并非是去节省AI的使用成本,而是借助模型具备的高并发以及低成本的特性,来取代人类所拥有的有限且昂贵的注意力投入。

你的AI需要一本员工手册
好多人在跟AI对话之际察觉到,它老是忘掉你项目的命名规范、架构限制或者先前碰到过的麻烦。处理这个问题的办法挺容易:将项目规则撰写成一份固定的文档。这个称作.md的文件,在AI每次开启会话时会自动读取。
架构决策能予以书写,命名约定也可书写,测试要求同样能够书写,团队反复犯下的错误也都可以写进去。这等同于给AI一本员工手册,使得它在你下达指令之前先将规矩看清楚。跟AI聊天仅仅是临时的沟通方式,而为它建立项目记忆才是长期下来的积累行为。

反复做的事应该做成技能
倘若你每日都得做同一桩事一回以上,像是审查代码,生成发布说明以及修复某一类重复的漏洞,那就不该每次都重新去敲提示词。正确的做法是将这些运作打包成一个能够重复实施的“技能”,借助一条命令便可跑完整个流程。
Code的缔造者Boris于社区中屡次着重强调此原则,一项技能即为一段能够执行的方法论,它并非依靠AI自身判断,而是由固定代码在先于AI犯错之际,阻挡所出现的问题,这便是有些团队敢于让AI在无人监督情形下运行的缘由,乃是由于边界已然被卡死了。

基础设施比模型聪明更重要
研究者对Code v2.1.88版本的51.2万行源代码进行了细致入微的分析,由此得出这样的结论,即其中仅有1.6%属于AI决策逻辑,而剩余的98.4%则是具有确定性的工程基础设施,这些基础设施涵盖了权限网关、上下文管理、工具路由以及错误恢复机制。
要说这个数字,并非是在表明模型贡献微小,而是在于说明这样子一个情况,即一个已然成熟的产品,其复杂程度并非体现在模型自身之上。可以搭建简化版基础设施的是普通开发者。.md以及hooks架构是那条截图里所呈现的,它与OpenAI内部的生产架构属于同一种模式,只是规模要小很多。
把错误信息直接变成修复指令

普通项目之中的错误提示乃是供人观看的,得要人工去进行理解以及修复。然而在成熟的人工智能工作流里面,错误信息自身便理应成为人工智能的修复指令。这是众多团队有所忽略但于杠杆效应方面幅度最大的细节之处。
等你下一回AI出现差错之际,暂且别动手去修正代码。而是向自己问上一句:我的项目文档之中少了何种规则?将此次差错撰写成一条约束,增添到.md文件之内。如此这般去做是在把人类工程师的判断力转化成机器能够读懂的指令,使得AI往后不会再犯相同类型的错误。
普通工程师今天就能动手做
那种范式已然发生了转移,你能够即刻着手去变更工作的方式。花费10分钟的时间,将你团队的架构规则、命名的约定、测试的要求书写下来,把它保存成为一个.md文件,放置在项目的根目录之处。把每一次AI出现错误之后所得到的经验补充进去,无需去追求尽善尽美,先让其运行起来。
与此同时,将你每日反复去做的举动化为技能。代码审查,生成发布说明,撰写测试用例,这些通通不应是手动输入提示词的工作。牢记那句话:要是你每天做某件事儿超过一回,那就使之变为能重复运行的办法。在未来五年,工程师的能力曲线正从“我能编写多少行代码”转变为“我能为人工智能营造多严谨的工作环境”。
倘若让你来思考,于你平日里开展的程序编写工作期间,首先应当被撰写成规范的那种反复出现从而令人苦恼的要点究竟是什么呢?欢迎于评论区域分享你的经历,通过点赞使更多的程序开发者能够瞧见这一套全新的思路。


