从实践中来，到问题中去：我在AIGC项目中的技术探索与成长
大家好，我是李航，一名从业五年的AIGC（人工智能生成内容）工程师。过去几年间，我参与过多个文本生成、图像生成、视频生成类项目的研发和落地。这些项目有的面向企业客户，也有的是消费级产品；有成功的喜悦，也有失败的教训。
这篇文章想和大家分享一下我在技术探索与实践过程中的一些真实经历和心得——技术不是空中楼阁，而是在不断试错与验证中逐渐成型的过程。
一、开篇：为什么要做“技术探索”？
在AIGC这个快速变化的领域，新技术层出不穷，模型迭代周期越来越短，业务需求也越来越复杂。作为一线开发者，我们经常面临这样一些情况：
- 市面上还没有现成的解决方案；
- 需求方提出了听起来“不可能”的功能；
- 已有的方案性能或成本难以满足实际场景；
- 我们需要提前预研技术路线，为未来做准备。
这个时候，就不得不进入一个相对模糊但又至关重要的阶段：技术探索。
这不是传统意义上的开发任务，也不是简单的调研报告，而是介于两者之间的一种状态。它要求我们既能动手实现原型，又要能评估风险与收益，最终为目标业务提供可靠的技术支撑。
二、一次真实的项目挑战：AI剧本助手
项目背景
2023年初，我所在的公司接到一个新项目：为影视编剧打造一款AI助手，目标是帮助编剧更高效地撰写剧本初稿。核心能力包括：
- 自动根据故事大纲生成分幕结构
- 生成角色台词并保持人设一致性
- 输出符合格式规范的剧本内容
- 支持中文口语化表达与情绪变化
看起来不难？但在当时，市面上并没有成熟的商用工具可以直接套用。我们需要从头开始设计一套基于语言模型的内容生成系统。
初期问题与挑战
我们尝试的第一版方案非常直接：调用公开的大模型API（如文心一言、通义千问等），通过Prompt工程生成内容。结果却不理想：
- 输出质量不稳定：有时生成的内容逻辑跳跃、语法错误频出；
- 人物性格容易崩塌：前几段还很“文艺”，下一段突然变得“市井”；
- 缺乏结构控制：用户希望输出剧本格式，但模型常常跳出Markdown乱写；
- API调用成本高且响应慢：对于长文本生成尤其明显；
- 本地推理资源不足：自建模型部署初期没有合适的硬件支持。
面对这些问题，我和团队陷入了思考：是继续优化Prompt，还是切换模型架构？是采用开源框架定制训练，还是寻找其他方式？
三、我们的技术方案与实现思路
最终我们确定了一个“混合策略+渐进式迭代”的路径：
第一步：构建可控的Prompt结构化模板
我们没有放弃Prompt工程，而是把它作为一个基础层，在其之上加了更多的控制机制：
def build_prompt(context):
return f"""
你是一个专业编剧助手，请根据以下信息生成剧本内容：
【故事背景】{context['background']}
【角色设定】{context['characters']}
【当前章节】第{context['act']}幕 - {context['scene']}
【风格要求】{context['style']}
请输出标准剧本格式，包含场景描述、角色对白，并保持人设一致。
"""
虽然效果有限，但这为我们后续的训练数据采集打下了基础。
第二步：引入LoRA微调，提升角色稳定性
由于预算有限，我们选择了基于HuggingFace Transformers + QLoRA微调技术的方式，对LLaMA2进行轻量级调整：
python run_clm.py \
--model_name_or_path meta-llama/Llama-2-7b-hf \
--dataset_name script_dataset.jsonl \
--output_dir ./models/script-llama \
--use_lora True \
--lora_r 8 \
--per_device_train_batch_size 2 \
...
关键点在于：
- 数据清洗极其重要。我们对大量剧本做了标注：角色名+表情标签+动作注释等；
- 微调时加入了“记忆窗口”管理，使模型在长对话中记住角色设定；
- 使用ChatML格式，统一输入输出格式。
这部分工作让我们看到了曙光，生成的人物对白变得更加稳定，情感表达也开始有了“张力”。
第三步：多模型协作 + 规则引擎补强
为了处理“结构化输出”问题，我们引入了一套规则驱动的后处理模块，负责：
- 检查是否按剧本格式输出；
- 校验角色名称是否存在；
- 自动补充舞台说明；
- 删除多余空格或重复句。
def postprocess(script_text, characters):
lines = [line.strip() for line in script_text.split('\n') if line.strip()]
processed = []
for line in lines:
# 判断是否为角色台词
if line.upper() in characters:
current_char = line.upper()
processed.append(f"[[{current_char}]]")
elif current_char and ':' in line:
name, content = line.split(':', 1)
if name.strip().upper() == current_char:
processed.append(f"{name}: {content}")
else:
# 其他为舞台说明或剧情描述
processed.append(f">> {line}")
return '\n'.join(processed)
这样的组合拳，让整体输出更加结构化，同时也更容易被下游工具使用（比如视频生成器、配音系统等）。
四、踩坑经验分享
在这个项目中，我也踩了不少坑，有些教训至今印象深刻：
1. 盲目追求最新模型，反而带来更大负担
一开始我们听说X系列模型特别适合叙事写作，果断投入资源去试用。结果发现它依赖的显卡型号根本买不到，推理时间也比预期长三倍。最终我们选择回归主流模型，稳扎稳打做适配。
✅ 教训：技术选型要兼顾效果和可行性，不要一味追新。
2. Prompt Engineering不能代替理解用户需求
我们曾花两周时间优化Prompt结构，结果上线后用户反馈说“太官方，不接地气”。后来我们才意识到，用户需要的是贴近生活、带点烟火气的对话风格，而不是“文学范”。
✅ 教训：模型可以模仿，但前提是对用户语境的理解。
3. 忽略数据质量带来的反噬
有一轮模型微调之后，测试结果很好，但上线后却频繁出现“性别混淆”“称呼错乱”等问题。回溯发现，是因为训练数据里存在大量未清洗的角色命名不一致现象。
✅ 教训：数据质量永远是第一位，干净的数据胜过任何高级技巧。
五、项目成果与效果总结
经过四个多月的努力，我们在以下几个方面取得了显著成果：
| 维度 | 上线前效果 | 实际上线后 | 提升幅度 |
|---|---|---|---|
| 对话角色一致性 | 约60% | 超90% | +50% |
| 文本流畅性评分 | 3.2/5 | 4.3/5 | +34% |
| 用户留存率 | 首日次日留存仅30% | 一周后留存稳定在67%以上 | +123% |
| 成本节约 | API调用量大，日均$120 | 内部部署后降至$20左右 | 降低83% |
更重要的是，这套系统成为我们后续多个内容创作类产品的底层平台，复用价值极高。
六、我的几点建议与经验分享
如果你也在做类似的技术探索工作，以下是我这几年总结出来的一些实用建议：
1. 技术探索 ≠ 盲目实验
要在明确目标的前提下推进探索。每做一个实验，都要回答清楚两个问题：
- 它能解决什么问题？
- 如果不做这个实验，会带来哪些损失？
这样才能避免陷入“为做而做”的陷阱。
2. 优先考虑可落地性，再谈先进性
很多技术听上去很酷炫，但一旦涉及部署、维护、监控、扩展，就会暴露出各种现实问题。选择技术方案时要综合考虑：
- 是否成熟？
- 社区活跃吗？
- 文档是否完善？
- 是否有人愿意长期维护？
3. 学会讲故事，给技术赋予“温度”
技术人员也要懂得讲“用户的故事”。只有真正理解用户的痛点，你才知道该在哪条路上坚持多久。有时候，一个看似“落后”的方案，可能才是最贴合用户的答案。
4. 记录过程比只看结果更重要
我们曾经有一个很有潜力的方向，因为前期没做好文档，几个月后回来想复盘却发现连参数都找不到了。技术探索本身就充满不确定性，只有详细记录过程，才能在未来做出更明智的判断。
七、结语：技术探索是一场修行
回顾整个项目的过程，我深刻体会到：技术探索不是简单地“试试看”，而是一种带着目标和责任的系统性工程。你需要对前沿趋势保持敏感，也要对现实条件保持敬畏。
每一次“试错”，都是对未来的一次投资；每一次“失败”，都是通往成功的垫脚石。
最后送给大家一句话，也是我一直贴在工位上的一句话：
“你可以走得很慢，但不能停下脚步。”
愿我们在AIGC这条路上越走越远，也欢迎你在评论区一起交流，分享你的实战经验！
如需文中代码仓库或更多细节，可以在GitHub私信我获取（GitHub ID: lihangcode）。
评论 0