开源 AIGC 赛道热起来后，真正难的是把工作流讲清楚
内容提要
开源AIGC赛道兴起，难点在于将AI工作流清晰化。真正有价值的是把AI参与开发的过程变成可复现、可审查、可维护的资产，而非仅分享提示词。普通团队应记录AI辅助步骤、边界条件和审查流程，避免关键步骤仅存于个人聊天记录中。
延伸解读
工作流开源的核心：可复现性
文章指出，AIGC工作流开源的关键在于可复现性。传统开源项目有代码、测试和文档，而AI工作流若只分享提示词，容易因模型版本、上下文或目录变化导致流程失效。真正有价值的是将AI参与开发的过程变成可复现、可审查、可维护的资产，而非仅展示顺滑的demo。
边界条件比提示词更重要
文章强调，边界条件比提示词更关键。例如，适合生成什么代码、不适合碰什么代码、由谁review、有无固定测试集、失败后如何处理等。真实工程中充满脏边角，AI可能给出看似合理但危险的改动，因此明确边界能避免部署链路中的告警和回滚。
普通团队应记录AI辅助步骤
文章建议普通团队先记录自己已在用的AI辅助步骤，包括允许使用的场景、必须人工写的场景、生成代码的检查流程、提示词和配置的存放位置，以及事故时的责任定位和回滚策略。避免关键步骤仅存于个人聊天记录，确保工作流不依赖个人。
Q&A
开源AIGC赛道中，真正困难的地方是什么？
真正困难的是把AI工作流讲清楚，使其可复现、可审查、可维护，而不仅仅是分享提示词。
为什么说只分享提示词是不够的？
因为提示词只是工作流的一部分，如果缺少边界条件（如适用场景、审查流程、测试集等），别人很难复现，且模型版本变化或上下文缺失都可能导致流程失效。
在AIGC工作流中，除了提示词，还需要关注哪些边界条件？
需要关注适合生成什么代码、不适合碰什么代码、生成结果由谁审查、是否有固定测试集、失败后是自动重试还是人工介入，以及是否禁止模型直接修改生产相关文件（如数据库迁移、权限配置等）。
为什么小团队在使用AI工具时最怕没人接得住？
因为小团队往往缺乏足够的人手来应对AI生成结果可能带来的问题，比如模型可能给出看似合理但实际有风险的改动，如果没有人及时审查和兜底，容易引发事故。
好的AIGC工作流分享应该包含哪些内容？
应该包含一次生成失败的记录、哪些输出被删除、哪些规则后来加入提示词、为什么将某些目录设为只读、为什么要求每次生成后运行同一组测试等粗糙但诚实的材料。
普通团队在应用AI辅助开发时，应该先做什么？
应该先把自己已经在用的AI辅助步骤写清楚，包括哪些场景允许用AI、哪些必须人工写、生成代码进仓库前要过哪些检查、提示词和配置放在哪里，以及模型输出导致事故时如何定位责任和回滚。
为什么说AI参与开发后，过程本身变成了工程资产？
因为AI参与开发后，工作流（如上下文组织方式、审查清单、回滚策略）变得可复现、可审查、可维护，成为团队可以长期依赖的工具，而不仅仅是个人习惯。
