评测 #3

New issue

Open

opened 2026-08-06 15:08:48 +08:00 by MuskZhou · 0 comments

MuskZhou commented 2026-08-06 15:08:48 +08:00

Copy link

评测一：项目定位与赛道契合度

1. 项目方向

云匠 · 精品短剧剧本创作引擎 是一个面向短剧创作者的AI全流程剧本生产系统，定位"精品短剧"而非"量产爽剧"。核心架构为 17个AI专家协同 + 六阶段子智能体验收体系，覆盖从创意捕手对话、故事大纲、人物小传、分集大纲到正剧剧本的完整创作链路。赛道为数字文化赛道（AI+文娱），同时可延伸至AI+教育（编剧教学）。

项目试图解决的核心痛点是：当前99%的AI编剧工具只做套路化爽剧生成，而精品短剧（现实题材、非遗文化、家庭伦理等）创作者缺乏系统化的AI辅助工具。

2. 优点

• 差异化定位清晰：明确区分"精品短剧"与"量产爽剧"，瞄准非遗文化、现实题材等蓝海领域，与2026年广电"微短剧精品创作传播计划"政策方向同频。
• 专家体系完整：17个专家覆盖创作全流程（灵魂捕手→项目策划→故事总监→结构架构→人物锻造→对白大师→场景工匠→视觉导演→合规守卫→质量审计→返工编辑→剧本审核等），对标人类编剧团队的分工。
• 方法论沉淀扎实：基于67000字创作方法论构建，包含"三层四维度"人物设计、"潜台词驱动"对白系统、"留白/侧面叙事"等文学性表达框架，不是简单的Prompt堆砌。
• 实战验证有数据：提供了卡卡星测评报告（双A+，88/85分），并附有《晚风载你》《电气工的眼泪》等实战案例的脱敏版测评摘要。

3. 问题或不清楚的地方

• "精品"标准的量化模糊：虽然提出了"潜台词密度""以物叙事占比""角色可辨识度"等评测维度，但这些指标在代码层面如何自动计算、如何与六阶段验收体系联动，目前看不到具体实现。
• 六阶段子智能体的"验收打分"机制停留在概念层：README中描述"持固定验收清单逐项打分（1-10），不合格自动点名责任专家返工"，但在 session_manager.py 和 server.py 中均未找到验收清单的代码实现，也看不到1-10分评分的逻辑。
• 赛道延展性存疑：AI+教育的延展方向（影视专业学生教学）目前只有Specs文档中的描述，没有对应的功能模块或课程化内容。

4. 下一步建议

1. 把"精品标准"代码化：在 engine/ 核心层增加可量化的质量评分模块（如对白重复度检测、叙事密度分析、人物一致性校验），让"精品"不只是Prompt里的要求，而是可自动打分的规则。
2. 落地六阶段验收体系：为每个节点设计结构化的验收清单（JSON Schema），由子智能体自动解析LLM输出并逐项校验，实现真正的"不合格→点名返工→复核闭环"。
3. 补充教学模块：如果要做AI+教育，建议增加"创作方法论解析"侧边栏，让用户在生成过程中能看到当前步骤对应的人类编剧理论（如三幕五层结构、节拍表原理），提升教育价值。

---

评测二：技术架构与工程实现

1. 项目方向

项目采用 FastAPI + 原生HTML/CSS/JS 的轻量技术栈，后端提供SSE流式接口，前端零框架依赖。架构上分为两套后端：

• 网关服务（server.py，Docker默认入口）：LLM代理 + SSE流式 + Session管理 + OpenAI兼容接口
• Agent后端（src/api/server.py）：完整Orchestrator工作流 + WebSocket实时对话

当前部署的是网关服务，前端通过SSE逐步调用各专家，后端代理转发LLM请求。

2. 优点

• 部署极简：Docker一键部署，环境变量配置即可运行，对比赛/演示场景非常友好。
• SSE流式体验好：创作过程全程透明，用户不需要等待整段生成完成，实时可见输出。
• Session管理完善：session_manager.py 实现了四节点交互模式的完整生命周期管理，包括创意捕手对话、节点生成/修改/确认、手动编辑保存、上下文压缩、节点回退与数据失效、Token/频次控制、JSON文件持久化。
• OpenAI兼容代理：/chat/completions 端点让前端可以直接调用，降低了接入门槛。
• Token消耗追踪：内置 _token_usage 统计，可按DeepSeek定价估算成本，对商业化运营有实际价值。
• 返工回滚机制：revision_editor 支持返工，go_back 支持节点回退并自动使下游节点失效，符合创作流程的迭代特性。

3. 问题或不清楚的地方

• 两套后端架构混乱：README中描述的"完整Orchestrator工作流"在 src/api/server.py，但当前Docker/Railway部署的是简化版网关服务 server.py。server.py 中的 /api/v1/create、/api/v1/step/{expert}、/api/v1/progress/{id} 均标注为 "Legacy/占位实现，未连接真实Orchestrator"。这意味着当前线上跑的是"阉割版"，17专家协同的完整工作流并未真正部署。
• 知识库加载是"伪实现"：README宣称10个专家使用外部知识库（knowledge/experts/ 下的MD文件），但 server.py 中的 _build_expert_system_prompt() 全部是硬编码的简化Prompt，没有看到任何从MD文件加载的逻辑。knowledge/experts/ 目录下的MD文件是否真实存在、内容质量如何，无法验证。
• 上下文压缩机制不完整：_compress_context() 方法注释说明"这里不能访问http_client，实际压缩会在server层完成"，但实际代码只是做了 content[:500] 的粗暴截断，没有真正调用LLM进行智能压缩。这会导致长剧本的上下文传递严重失真。
• 专家编号体系不一致：SPECS_W1.md中使用 §0-§15 编号，README中使用 0-16 编号，server.py 中的 EXPERT_PROMPT_MAP 又使用另一套ID映射（如 mission_commander 对应 §9 创意捕手，但 session_manager.py 中根本没有这个专家）。同一项目内三套命名体系，维护成本极高。
• 内存级状态易丢失：_token_usage 和 _rate_buckets 都是全局内存变量，服务重启即清零。Session数据虽然持久化到JSON文件，但Token消耗统计和限流状态没有持久化。
• 测试覆盖不透明：tests/ 目录存在，但仓库中看不到测试用例的具体内容和覆盖率数据。

4. 下一步建议

1. 合并或明确两套后端的分工：要么把 src/api/server.py 的Orchestrator能力迁移到 server.py，要么明确网关服务只负责代理，复杂工作流走Agent后端，并在文档中清晰说明。
2. 实现真正的知识库加载：在 _build_expert_system_prompt() 中增加从 knowledge/experts/{expert_id}.md 读取文件的逻辑，支持热更新（可用 watchdog 监控文件变更）。
3. 修复上下文压缩：在 server.py 层完成真正的LLM压缩调用，或改用更智能的摘要算法（如提取关键实体+关系图谱），避免粗暴截断导致信息丢失。
4. 统一专家命名体系：建议以 session_manager.py 中的 NODE_EXPERTS 和四节点模型为基准，统一所有文档和代码中的专家ID、名称、编号。
5. 增加Redis/数据库持久化：将 _token_usage、限流状态、Session数据迁移到Redis或SQLite，支持多实例部署和数据不丢失。

---

评测三：前端交互与用户体验

1. 项目方向

前端采用 原生HTML/CSS/JS（零框架依赖），提供 demo-v7.html 作为当前主界面。设计上强调"全屏画布模式"（A4纸式无限高画布）、"深浅色双主题"（现代玻璃拟态UI）、"SSE流式输出实时可见"、"6阶段结构化面板实时反馈创作进度"。

2. 优点

• 零框架依赖：不依赖React/Vue/Angular，单HTML文件即可运行，极大降低了部署和维护成本，也支持"前端独立使用"模式（直接填入API配置即可）。
• SSE流式输出：创作过程实时可见，减少了用户等待焦虑，提升了"AI在为我工作"的感知。
• 双主题设计：深浅色主题通过CSS变量切换，玻璃拟态UI符合现代审美。
• 四节点交互模式清晰：故事大纲→人物小传→分集大纲→正剧剧本的递进式流程，符合人类编剧的实际工作习惯，降低了认知负担。
• 创意捕手对话：用"轻松聊天"的方式替代传统的表单填写，降低了用户启动门槛，同时通过追问机制收集必要信息。

3. 问题或不清楚的地方

• 前端与后端的能力断层：前端宣传"17专家协同""六阶段子智能体验收"，但当前部署的网关服务实际上只提供了通用的SSE流式代理，前端需要自行组装Prompt调用各专家。这意味着"17专家协同"更多是前端的"概念包装"，而非后端的真实工作流编排。
• demo-v7.html 的版本号暗示迭代混乱：文件名中的 v7 表明前端经历了多次重构，但仓库中没有看到v1-v6的历史版本，也没有设计文档说明每次迭代的改进点。
• "全屏画布模式"和"A4纸式无限高画布"的实现细节不清楚：从仓库文件列表中无法确认这些交互特性是否已在 demo-v7.html 中完整实现，还是仅停留在设计文档中。
• 缺乏移动端适配：短剧创作者很可能在平板或手机上查看/编辑剧本，原生HTML如果没有响应式设计，移动端体验会很差。
• 没有用户反馈入口：创作过程中用户如何对AI输出进行"部分接受/部分修改"？目前只看到"确认"和"整体修改"两种操作，缺乏细粒度的交互（如划线批注、局部重写）。

4. 下一步建议

1. 前后端能力对齐：如果后端暂时无法部署完整Orchestrator，前端应该诚实展示当前能力边界（如"当前为单专家模式，完整协同工作流开发中"），避免过度承诺。
2. 增加细粒度交互：支持用户对AI输出进行"选中重写""批注反馈""对比版本"等操作，而不是只能"全接受"或"全拒绝"。
3. 响应式设计：为平板和手机优化布局，短剧创作者的使用场景很可能不限于桌面端。
4. 前端版本管理：将前端代码拆分为模块化文件（即使不使用框架，也可以用ES Modules），并补充前端架构文档。

---

评测四：商业模式与商业化潜力

1. 项目方向

项目面向独立编剧、小型短剧工作室、非遗文化创作者、影视专业学生等群体，试图通过"1人+17个AI专家=完整制作团队"的模式降低精品短剧的创作门槛和成本。

2. 优点

• 目标用户画像清晰：四类用户（独立编剧、非遗创作者、小工作室、影视学生）的痛点描述准确，尤其是"感觉不对但不知道哪里不对"这句，精准击中了非专业创作者的困境。
• 成本优势明确：传统精品短剧编剧团队需要5-10人，本引擎试图用AI替代其中的大部分岗位，对预算有限的小团队有吸引力。
• 政策红利：2026年广电"微短剧精品创作传播计划"明确扶持现实题材+精品化，6大平台60亿+专项资金，政策环境有利。
• Token成本可控：按DeepSeek定价（input ¥1/M tokens, output ¥2/M tokens），单次创作全流程的API成本可能在几元到十几元之间，有清晰的成本模型。
• 可扩展的收费模式：支持自定义API接入（用户可自带API Key），未来可以按"基础版（自带Key）+ 专业版（平台提供Key+高级功能）"分层收费。

3. 问题或不清楚的地方

• 竞品分析缺失：虽然对比了"市面AI编剧工具"，但没有具体点名任何竞品（如ScriptAI、Dramatica、国内的某些AI编剧产品），缺乏客观的市场格局分析。
• 用户获取路径不清晰：短剧创作者如何知道这个工具？是通过B站/抖音内容营销、与短剧平台合作、还是与影视院校合作？没有用户增长策略。
• 精品短剧的"精品"谁来定义：引擎生成后，最终还是要经过平台审核和观众检验。如果平台方不认可AI生成的剧本，或者观众不买账，工具的价值会大打折扣。
• 版权归属模糊：AI生成的剧本版权归属如何界定？用户输入的创意方向+AI生成的完整剧本，版权是用户独有还是平台共享？这在商业化前必须明确。
• 变现模式单一：目前只看到"工具收费"一条路，没有考虑"剧本交易平台""创作者社区""与短剧制作方分成"等多元变现可能。

4. 下一步建议

1. 补充竞品深度分析：选择2-3个直接竞品，从功能、定价、用户体验、输出质量四个维度做详细对比表格，明确差异化优势。
2. 设计用户增长飞轮：建议与1-2家短剧平台或MCN机构建立合作，用"免费试用+案例背书"的方式获取种子用户，同时积累真实反馈数据。
3. 明确版权条款：在README和前端界面中增加"AI生成内容版权说明"，建议采用"用户输入部分版权归用户，AI生成部分用户享有使用权"的条款，降低法律风险。
4. 探索B端变现：除了C端创作者，短剧平台、影视公司、广告 agency 可能是更大的付费方。可以设计"企业版"，支持品牌定制、团队协作、私有知识库部署。

---

评测五：代码质量与可维护性

1. 项目方向

项目使用 Python 3.11+ + FastAPI，代码结构分为网关层、Session管理层、路由层、引擎核心层、专家模块层、知识库层。目标是构建一个模块化、可扩展的AI创作引擎。

2. 优点

• 代码风格统一：使用Pydantic模型定义请求/响应结构，类型注解覆盖较全，符合Python工程规范。
• 模块化设计：session_manager.py 和 session_routes.py 职责分离，Session的生命周期管理和API路由解耦，便于测试和维护。
• 环境变量配置灵活：LLM API Key、Base URL、Model、Host、Port、Gateway Token 均可通过环境变量配置，支持多环境部署。
• CORS全开：allow_origins=["*"] 虽然生产环境不安全，但对比赛演示和开发调试非常友好。
• 错误处理基本到位：流式调用中捕获了超时异常、HTTP错误、JSON解析错误，并返回友好的SSE错误事件。

3. 问题或不清楚的地方

• 大量占位代码：server.py 中的 /api/v1/create、/api/v1/step/{expert}、/api/v1/progress/{id} 三个核心接口均为占位实现，直接返回warning提示用户使用 /api/v1/stream。这意味着项目的"完整工作流"能力尚未实现。
• 重复代码：server.py 和 session_manager.py 中都有 _stream_llm() 方法，逻辑几乎完全一致，没有抽取到公共模块。
• 硬编码魔法数字：MAX_REVISIONS_PER_NODE = 3、MAX_API_CALLS_PER_HOUR = 30、CONTEXT_SUMMARY_MAX_CHARS = 500、RATE_LIMIT_MAX = 30 等阈值分散在各处，没有集中配置。
• 缺少日志系统：没有看到任何 logging 模块的使用，生产环境排查问题会很困难。
• 缺少输入校验：虽然Pydantic模型做了基础校验，但对用户输入的内容长度、敏感词、注入攻击等没有额外防护。
• TODO未处理：session_manager.py 中明确标注 TODO: 在session_routes.py相关接口中增加access_token校验（比赛阶段暂不启用），说明安全校验尚未完成。

4. 下一步建议

1. 清理占位代码：要么实现 /api/v1/create 等接口的完整工作流，要么直接删除这些接口，避免误导用户。
2. 抽取公共模块：将 _stream_llm()、_get_llm_config()、SSE事件格式化等逻辑抽取到 src/utils/ 或 src/core/ 公共模块，消除重复代码。
3. 引入配置中心：使用 pydantic-settings 或 YAML 配置文件集中管理所有阈值参数，支持按环境覆盖。
4. 增加日志和监控：引入 structlog 或标准 logging，记录关键操作（Session创建、节点生成、API调用、错误），并暴露 /metrics 端点供Prometheus采集。
5. 完成安全校验：落实 access_token 校验，增加内容安全过滤（敏感词、Prompt注入防护），为生产环境做准备。

---

评测六：文档与社区建设

1. 项目方向

项目文档包括 README.md、SPECS_W1.md、CONTRIBUTING.md、SUBMISSIONS.md，以及 docs/ 目录下的架构设计、知识库、测评报告等。目标是为比赛评审和潜在用户提供完整的项目说明。

2. 优点

• README信息密度高：核心能力、架构图、专家清单、快速开始、环境变量、技术栈一目了然，新用户可以在5分钟内了解项目全貌。
• Specs文档专业：SPECS_W1.md 从应用场景、目标用户、解决方案、差异化优势、评测标准、技术架构、MVP交付范围七个维度进行了系统阐述，体现了产品经理思维。
• 测评报告透明：主动公开卡卡星测评摘要（脱敏版PDF），展示了对自身质量的信心，也为评审提供了客观依据。
• 知识库结构清晰：knowledge/culture/（中华优秀传统文化）和 knowledge/experts/（专家Prompt）分离，便于后续扩展。
• 架构文档持续更新：commit记录显示架构文档经历了多次修正（"统一架构文档 - 修正启动命令/明确后端职责/17专家清单"），说明文档维护是持续的。

3. 问题或不清楚的地方

• CONTRIBUTING.md 和 SUBMISSIONS.md 是模板：从commit记录看，这两个文件是"Initialize track repository"时创建的，内容可能是比赛平台模板，没有看到项目特有的贡献指南或提交规范。
• API文档缺失：虽然有README中的接口列表，但没有Swagger/OpenAPI的详细说明（FastAPI自带 /docs，但README没有提及）。
• 知识库内容不可见：knowledge/experts/ 下的10个MD文件是核心资产，但仓库浏览时无法直接查看其内容质量，也无法确认是否与 server.py 中的硬编码Prompt一致。
• 变更日志（CHANGELOG）缺失：从6月25日初始化到8月6日的频繁提交（专家知识来源标注优化、返工回滚机制、token消耗追踪、六阶段子智能体等），但没有CHANGELOG记录每次版本的核心变更。
• 社区互动为零：Issues 和 Pull requests 均为0，说明目前还是单人开发，没有社区贡献者。

4. 下一步建议

1. 激活社区：在README中增加"如何贡献"章节，明确欢迎外部贡献者补充专家Prompt、提交测试用例、优化前端UI。
2. 补充API文档：在README中增加 http://localhost:8000/docs 的说明，并补充几个典型的curl调用示例。
3. 建立CHANGELOG：从当前版本开始记录每次Release的变更点，便于用户追踪功能演进。
4. 开放知识库预览：在README中摘录1-2个专家知识库的核心片段，展示方法论深度，吸引潜在用户和贡献者。
5. 补充故障排查指南：增加"常见问题"（FAQ）章节，如"API Key配置错误如何处理""SSE连接断开怎么办""Token消耗过高如何优化"等。

---

总体评分（供参考）

维度	评分	说明
项目方向	⭐⭐⭐⭐⭐	定位精准，赛道契合度高，差异化明显
技术实现	⭐⭐⭐☆☆	基础能力扎实，但核心工作流尚未完整落地，架构存在混乱
用户体验	⭐⭐⭐⭐☆	四节点流程清晰，SSE体验好，但前后端能力存在断层
商业潜力	⭐⭐⭐⭐☆	目标用户明确，成本模型清晰，但增长策略和变现模式需补充
代码质量	⭐⭐⭐☆☆	模块化设计好，但占位代码多、重复代码、缺少日志和测试
文档建设	⭐⭐⭐⭐☆	信息密度高，Specs专业，但API文档、CHANGELOG、社区建设待加强

综合：⭐⭐⭐⭐☆（3.8/5） — 方向正确、方法论扎实、演示体验好，但需要从"概念验证"尽快推进到"完整产品"，核心工作流的代码落地是当前最大瓶颈。

## 评测一：项目定位与赛道契合度 ### 1. 项目方向 **云匠 · 精品短剧剧本创作引擎** 是一个面向短剧创作者的AI全流程剧本生产系统，定位"精品短剧"而非"量产爽剧"。核心架构为 **17个AI专家协同 + 六阶段子智能体验收体系**，覆盖从创意捕手对话、故事大纲、人物小传、分集大纲到正剧剧本的完整创作链路。赛道为数字文化赛道（AI+文娱），同时可延伸至AI+教育（编剧教学）。 项目试图解决的核心痛点是：当前99%的AI编剧工具只做套路化爽剧生成，而精品短剧（现实题材、非遗文化、家庭伦理等）创作者缺乏系统化的AI辅助工具。 ### 2. 优点 - **差异化定位清晰**：明确区分"精品短剧"与"量产爽剧"，瞄准非遗文化、现实题材等蓝海领域，与2026年广电"微短剧精品创作传播计划"政策方向同频。 - **专家体系完整**：17个专家覆盖创作全流程（灵魂捕手→项目策划→故事总监→结构架构→人物锻造→对白大师→场景工匠→视觉导演→合规守卫→质量审计→返工编辑→剧本审核等），对标人类编剧团队的分工。 - **方法论沉淀扎实**：基于67000字创作方法论构建，包含"三层四维度"人物设计、"潜台词驱动"对白系统、"留白/侧面叙事"等文学性表达框架，不是简单的Prompt堆砌。 - **实战验证有数据**：提供了卡卡星测评报告（双A+，88/85分），并附有《晚风载你》《电气工的眼泪》等实战案例的脱敏版测评摘要。 ### 3. 问题或不清楚的地方 - **"精品"标准的量化模糊**：虽然提出了"潜台词密度""以物叙事占比""角色可辨识度"等评测维度，但这些指标在代码层面如何自动计算、如何与六阶段验收体系联动，目前看不到具体实现。 - **六阶段子智能体的"验收打分"机制停留在概念层**：README中描述"持固定验收清单逐项打分（1-10），不合格自动点名责任专家返工"，但在 `session_manager.py` 和 `server.py` 中均未找到验收清单的代码实现，也看不到1-10分评分的逻辑。 - **赛道延展性存疑**：AI+教育的延展方向（影视专业学生教学）目前只有Specs文档中的描述，没有对应的功能模块或课程化内容。 ### 4. 下一步建议 1. **把"精品标准"代码化**：在 `engine/` 核心层增加可量化的质量评分模块（如对白重复度检测、叙事密度分析、人物一致性校验），让"精品"不只是Prompt里的要求，而是可自动打分的规则。 2. **落地六阶段验收体系**：为每个节点设计结构化的验收清单（JSON Schema），由子智能体自动解析LLM输出并逐项校验，实现真正的"不合格→点名返工→复核闭环"。 3. **补充教学模块**：如果要做AI+教育，建议增加"创作方法论解析"侧边栏，让用户在生成过程中能看到当前步骤对应的人类编剧理论（如三幕五层结构、节拍表原理），提升教育价值。 --- ## 评测二：技术架构与工程实现 ### 1. 项目方向 项目采用 **FastAPI + 原生HTML/CSS/JS** 的轻量技术栈，后端提供SSE流式接口，前端零框架依赖。架构上分为两套后端： - **网关服务**（`server.py`，Docker默认入口）：LLM代理 + SSE流式 + Session管理 + OpenAI兼容接口 - **Agent后端**（`src/api/server.py`）：完整Orchestrator工作流 + WebSocket实时对话 当前部署的是网关服务，前端通过SSE逐步调用各专家，后端代理转发LLM请求。 ### 2. 优点 - **部署极简**：Docker一键部署，环境变量配置即可运行，对比赛/演示场景非常友好。 - **SSE流式体验好**：创作过程全程透明，用户不需要等待整段生成完成，实时可见输出。 - **Session管理完善**：`session_manager.py` 实现了四节点交互模式的完整生命周期管理，包括创意捕手对话、节点生成/修改/确认、手动编辑保存、上下文压缩、节点回退与数据失效、Token/频次控制、JSON文件持久化。 - **OpenAI兼容代理**：`/chat/completions` 端点让前端可以直接调用，降低了接入门槛。 - **Token消耗追踪**：内置 `_token_usage` 统计，可按DeepSeek定价估算成本，对商业化运营有实际价值。 - **返工回滚机制**：`revision_editor` 支持返工，`go_back` 支持节点回退并自动使下游节点失效，符合创作流程的迭代特性。 ### 3. 问题或不清楚的地方 - **两套后端架构混乱**：README中描述的"完整Orchestrator工作流"在 `src/api/server.py`，但当前Docker/Railway部署的是简化版网关服务 `server.py`。`server.py` 中的 `/api/v1/create`、`/api/v1/step/{expert}`、`/api/v1/progress/{id}` 均标注为 **"Legacy/占位实现，未连接真实Orchestrator"**。这意味着当前线上跑的是"阉割版"，17专家协同的完整工作流并未真正部署。 - **知识库加载是"伪实现"**：README宣称10个专家使用外部知识库（`knowledge/experts/` 下的MD文件），但 `server.py` 中的 `_build_expert_system_prompt()` 全部是硬编码的简化Prompt，没有看到任何从MD文件加载的逻辑。`knowledge/experts/` 目录下的MD文件是否真实存在、内容质量如何，无法验证。 - **上下文压缩机制不完整**：`_compress_context()` 方法注释说明"这里不能访问http_client，实际压缩会在server层完成"，但实际代码只是做了 `content[:500]` 的粗暴截断，没有真正调用LLM进行智能压缩。这会导致长剧本的上下文传递严重失真。 - **专家编号体系不一致**：SPECS_W1.md中使用 §0-§15 编号，README中使用 0-16 编号，`server.py` 中的 `EXPERT_PROMPT_MAP` 又使用另一套ID映射（如 `mission_commander` 对应 §9 创意捕手，但 `session_manager.py` 中根本没有这个专家）。同一项目内三套命名体系，维护成本极高。 - **内存级状态易丢失**：`_token_usage` 和 `_rate_buckets` 都是全局内存变量，服务重启即清零。Session数据虽然持久化到JSON文件，但Token消耗统计和限流状态没有持久化。 - **测试覆盖不透明**：`tests/` 目录存在，但仓库中看不到测试用例的具体内容和覆盖率数据。 ### 4. 下一步建议 1. **合并或明确两套后端的分工**：要么把 `src/api/server.py` 的Orchestrator能力迁移到 `server.py`，要么明确网关服务只负责代理，复杂工作流走Agent后端，并在文档中清晰说明。 2. **实现真正的知识库加载**：在 `_build_expert_system_prompt()` 中增加从 `knowledge/experts/{expert_id}.md` 读取文件的逻辑，支持热更新（可用 `watchdog` 监控文件变更）。 3. **修复上下文压缩**：在 `server.py` 层完成真正的LLM压缩调用，或改用更智能的摘要算法（如提取关键实体+关系图谱），避免粗暴截断导致信息丢失。 4. **统一专家命名体系**：建议以 `session_manager.py` 中的 `NODE_EXPERTS` 和四节点模型为基准，统一所有文档和代码中的专家ID、名称、编号。 5. **增加Redis/数据库持久化**：将 `_token_usage`、限流状态、Session数据迁移到Redis或SQLite，支持多实例部署和数据不丢失。 --- ## 评测三：前端交互与用户体验 ### 1. 项目方向 前端采用 **原生HTML/CSS/JS（零框架依赖）**，提供 `demo-v7.html` 作为当前主界面。设计上强调"全屏画布模式"（A4纸式无限高画布）、"深浅色双主题"（现代玻璃拟态UI）、"SSE流式输出实时可见"、"6阶段结构化面板实时反馈创作进度"。 ### 2. 优点 - **零框架依赖**：不依赖React/Vue/Angular，单HTML文件即可运行，极大降低了部署和维护成本，也支持"前端独立使用"模式（直接填入API配置即可）。 - **SSE流式输出**：创作过程实时可见，减少了用户等待焦虑，提升了"AI在为我工作"的感知。 - **双主题设计**：深浅色主题通过CSS变量切换，玻璃拟态UI符合现代审美。 - **四节点交互模式清晰**：故事大纲→人物小传→分集大纲→正剧剧本的递进式流程，符合人类编剧的实际工作习惯，降低了认知负担。 - **创意捕手对话**：用"轻松聊天"的方式替代传统的表单填写，降低了用户启动门槛，同时通过追问机制收集必要信息。 ### 3. 问题或不清楚的地方 - **前端与后端的能力断层**：前端宣传"17专家协同""六阶段子智能体验收"，但当前部署的网关服务实际上只提供了通用的SSE流式代理，前端需要自行组装Prompt调用各专家。这意味着"17专家协同"更多是前端的"概念包装"，而非后端的真实工作流编排。 - **demo-v7.html 的版本号暗示迭代混乱**：文件名中的 `v7` 表明前端经历了多次重构，但仓库中没有看到v1-v6的历史版本，也没有设计文档说明每次迭代的改进点。 - **"全屏画布模式"和"A4纸式无限高画布"的实现细节不清楚**：从仓库文件列表中无法确认这些交互特性是否已在 `demo-v7.html` 中完整实现，还是仅停留在设计文档中。 - **缺乏移动端适配**：短剧创作者很可能在平板或手机上查看/编辑剧本，原生HTML如果没有响应式设计，移动端体验会很差。 - **没有用户反馈入口**：创作过程中用户如何对AI输出进行"部分接受/部分修改"？目前只看到"确认"和"整体修改"两种操作，缺乏细粒度的交互（如划线批注、局部重写）。 ### 4. 下一步建议 1. **前后端能力对齐**：如果后端暂时无法部署完整Orchestrator，前端应该诚实展示当前能力边界（如"当前为单专家模式，完整协同工作流开发中"），避免过度承诺。 2. **增加细粒度交互**：支持用户对AI输出进行"选中重写""批注反馈""对比版本"等操作，而不是只能"全接受"或"全拒绝"。 3. **响应式设计**：为平板和手机优化布局，短剧创作者的使用场景很可能不限于桌面端。 4. **前端版本管理**：将前端代码拆分为模块化文件（即使不使用框架，也可以用ES Modules），并补充前端架构文档。 --- ## 评测四：商业模式与商业化潜力 ### 1. 项目方向 项目面向独立编剧、小型短剧工作室、非遗文化创作者、影视专业学生等群体，试图通过"1人+17个AI专家=完整制作团队"的模式降低精品短剧的创作门槛和成本。 ### 2. 优点 - **目标用户画像清晰**：四类用户（独立编剧、非遗创作者、小工作室、影视学生）的痛点描述准确，尤其是"感觉不对但不知道哪里不对"这句，精准击中了非专业创作者的困境。 - **成本优势明确**：传统精品短剧编剧团队需要5-10人，本引擎试图用AI替代其中的大部分岗位，对预算有限的小团队有吸引力。 - **政策红利**：2026年广电"微短剧精品创作传播计划"明确扶持现实题材+精品化，6大平台60亿+专项资金，政策环境有利。 - **Token成本可控**：按DeepSeek定价（input ¥1/M tokens, output ¥2/M tokens），单次创作全流程的API成本可能在几元到十几元之间，有清晰的成本模型。 - **可扩展的收费模式**：支持自定义API接入（用户可自带API Key），未来可以按"基础版（自带Key）+ 专业版（平台提供Key+高级功能）"分层收费。 ### 3. 问题或不清楚的地方 - **竞品分析缺失**：虽然对比了"市面AI编剧工具"，但没有具体点名任何竞品（如ScriptAI、Dramatica、国内的某些AI编剧产品），缺乏客观的市场格局分析。 - **用户获取路径不清晰**：短剧创作者如何知道这个工具？是通过B站/抖音内容营销、与短剧平台合作、还是与影视院校合作？没有用户增长策略。 - **精品短剧的"精品"谁来定义**：引擎生成后，最终还是要经过平台审核和观众检验。如果平台方不认可AI生成的剧本，或者观众不买账，工具的价值会大打折扣。 - **版权归属模糊**：AI生成的剧本版权归属如何界定？用户输入的创意方向+AI生成的完整剧本，版权是用户独有还是平台共享？这在商业化前必须明确。 - **变现模式单一**：目前只看到"工具收费"一条路，没有考虑"剧本交易平台""创作者社区""与短剧制作方分成"等多元变现可能。 ### 4. 下一步建议 1. **补充竞品深度分析**：选择2-3个直接竞品，从功能、定价、用户体验、输出质量四个维度做详细对比表格，明确差异化优势。 2. **设计用户增长飞轮**：建议与1-2家短剧平台或MCN机构建立合作，用"免费试用+案例背书"的方式获取种子用户，同时积累真实反馈数据。 3. **明确版权条款**：在README和前端界面中增加"AI生成内容版权说明"，建议采用"用户输入部分版权归用户，AI生成部分用户享有使用权"的条款，降低法律风险。 4. **探索B端变现**：除了C端创作者，短剧平台、影视公司、广告 agency 可能是更大的付费方。可以设计"企业版"，支持品牌定制、团队协作、私有知识库部署。 --- ## 评测五：代码质量与可维护性 ### 1. 项目方向 项目使用 Python 3.11+ + FastAPI，代码结构分为网关层、Session管理层、路由层、引擎核心层、专家模块层、知识库层。目标是构建一个模块化、可扩展的AI创作引擎。 ### 2. 优点 - **代码风格统一**：使用Pydantic模型定义请求/响应结构，类型注解覆盖较全，符合Python工程规范。 - **模块化设计**：`session_manager.py` 和 `session_routes.py` 职责分离，Session的生命周期管理和API路由解耦，便于测试和维护。 - **环境变量配置灵活**：LLM API Key、Base URL、Model、Host、Port、Gateway Token 均可通过环境变量配置，支持多环境部署。 - **CORS全开**：`allow_origins=["*"]` 虽然生产环境不安全，但对比赛演示和开发调试非常友好。 - **错误处理基本到位**：流式调用中捕获了超时异常、HTTP错误、JSON解析错误，并返回友好的SSE错误事件。 ### 3. 问题或不清楚的地方 - **大量占位代码**：`server.py` 中的 `/api/v1/create`、`/api/v1/step/{expert}`、`/api/v1/progress/{id}` 三个核心接口均为占位实现，直接返回warning提示用户使用 `/api/v1/stream`。这意味着项目的"完整工作流"能力尚未实现。 - **重复代码**：`server.py` 和 `session_manager.py` 中都有 `_stream_llm()` 方法，逻辑几乎完全一致，没有抽取到公共模块。 - **硬编码魔法数字**：`MAX_REVISIONS_PER_NODE = 3`、`MAX_API_CALLS_PER_HOUR = 30`、`CONTEXT_SUMMARY_MAX_CHARS = 500`、`RATE_LIMIT_MAX = 30` 等阈值分散在各处，没有集中配置。 - **缺少日志系统**：没有看到任何 `logging` 模块的使用，生产环境排查问题会很困难。 - **缺少输入校验**：虽然Pydantic模型做了基础校验，但对用户输入的内容长度、敏感词、注入攻击等没有额外防护。 - **TODO未处理**：`session_manager.py` 中明确标注 `TODO: 在session_routes.py相关接口中增加access_token校验（比赛阶段暂不启用）`，说明安全校验尚未完成。 ### 4. 下一步建议 1. **清理占位代码**：要么实现 `/api/v1/create` 等接口的完整工作流，要么直接删除这些接口，避免误导用户。 2. **抽取公共模块**：将 `_stream_llm()`、`_get_llm_config()`、SSE事件格式化等逻辑抽取到 `src/utils/` 或 `src/core/` 公共模块，消除重复代码。 3. **引入配置中心**：使用 `pydantic-settings` 或 YAML 配置文件集中管理所有阈值参数，支持按环境覆盖。 4. **增加日志和监控**：引入 `structlog` 或标准 `logging`，记录关键操作（Session创建、节点生成、API调用、错误），并暴露 `/metrics` 端点供Prometheus采集。 5. **完成安全校验**：落实 `access_token` 校验，增加内容安全过滤（敏感词、Prompt注入防护），为生产环境做准备。 --- ## 评测六：文档与社区建设 ### 1. 项目方向 项目文档包括 README.md、SPECS_W1.md、CONTRIBUTING.md、SUBMISSIONS.md，以及 docs/ 目录下的架构设计、知识库、测评报告等。目标是为比赛评审和潜在用户提供完整的项目说明。 ### 2. 优点 - **README信息密度高**：核心能力、架构图、专家清单、快速开始、环境变量、技术栈一目了然，新用户可以在5分钟内了解项目全貌。 - **Specs文档专业**：SPECS_W1.md 从应用场景、目标用户、解决方案、差异化优势、评测标准、技术架构、MVP交付范围七个维度进行了系统阐述，体现了产品经理思维。 - **测评报告透明**：主动公开卡卡星测评摘要（脱敏版PDF），展示了对自身质量的信心，也为评审提供了客观依据。 - **知识库结构清晰**：`knowledge/culture/`（中华优秀传统文化）和 `knowledge/experts/`（专家Prompt）分离，便于后续扩展。 - **架构文档持续更新**：commit记录显示架构文档经历了多次修正（"统一架构文档 - 修正启动命令/明确后端职责/17专家清单"），说明文档维护是持续的。 ### 3. 问题或不清楚的地方 - **CONTRIBUTING.md 和 SUBMISSIONS.md 是模板**：从commit记录看，这两个文件是"Initialize track repository"时创建的，内容可能是比赛平台模板，没有看到项目特有的贡献指南或提交规范。 - **API文档缺失**：虽然有README中的接口列表，但没有Swagger/OpenAPI的详细说明（FastAPI自带 `/docs`，但README没有提及）。 - **知识库内容不可见**：`knowledge/experts/` 下的10个MD文件是核心资产，但仓库浏览时无法直接查看其内容质量，也无法确认是否与 `server.py` 中的硬编码Prompt一致。 - **变更日志（CHANGELOG）缺失**：从6月25日初始化到8月6日的频繁提交（专家知识来源标注优化、返工回滚机制、token消耗追踪、六阶段子智能体等），但没有CHANGELOG记录每次版本的核心变更。 - **社区互动为零**：Issues 和 Pull requests 均为0，说明目前还是单人开发，没有社区贡献者。 ### 4. 下一步建议 1. **激活社区**：在README中增加"如何贡献"章节，明确欢迎外部贡献者补充专家Prompt、提交测试用例、优化前端UI。 2. **补充API文档**：在README中增加 `http://localhost:8000/docs` 的说明，并补充几个典型的curl调用示例。 3. **建立CHANGELOG**：从当前版本开始记录每次Release的变更点，便于用户追踪功能演进。 4. **开放知识库预览**：在README中摘录1-2个专家知识库的核心片段，展示方法论深度，吸引潜在用户和贡献者。 5. **补充故障排查指南**：增加"常见问题"（FAQ）章节，如"API Key配置错误如何处理""SSE连接断开怎么办""Token消耗过高如何优化"等。 --- ## 总体评分（供参考） | 维度 | 评分 | 说明 | |------|------|------| | 项目方向 | ⭐⭐⭐⭐⭐ | 定位精准，赛道契合度高，差异化明显 | | 技术实现 | ⭐⭐⭐☆☆ | 基础能力扎实，但核心工作流尚未完整落地，架构存在混乱 | | 用户体验 | ⭐⭐⭐⭐☆ | 四节点流程清晰，SSE体验好，但前后端能力存在断层 | | 商业潜力 | ⭐⭐⭐⭐☆ | 目标用户明确，成本模型清晰，但增长策略和变现模式需补充 | | 代码质量 | ⭐⭐⭐☆☆ | 模块化设计好，但占位代码多、重复代码、缺少日志和测试 | | 文档建设 | ⭐⭐⭐⭐☆ | 信息密度高，Specs专业，但API文档、CHANGELOG、社区建设待加强 | **综合：⭐⭐⭐⭐☆（3.8/5）** — 方向正确、方法论扎实、演示体验好，但需要从"概念验证"尽快推进到"完整产品"，核心工作流的代码落地是当前最大瓶颈。

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

No results found.

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

xiaoduan/track-108#3

No description provided.