1026 lines
32 KiB
Python
1026 lines
32 KiB
Python
"""
|
||
AI Prompt 集中管理
|
||
|
||
所有 AI 相关 prompt 模板放在此处，避免在 services 中硬编码。
|
||
使用 .format() 或 f-string 时需保证占位符与调用处一致。
|
||
"""
|
||
|
||
# ============================================================================
|
||
# 影响分析
|
||
# ============================================================================
|
||
|
||
PROMPT_IMPACT_ANALYSIS = """
|
||
Analyze the following news/signal for an AI engineering team.
|
||
Determine its "Impact Score" (0.0 to 1.0) based on how critical it is for our RAG/LLM development.
|
||
|
||
Signal: "{signal_content}"
|
||
|
||
Rules:
|
||
- 0.9-1.0: Major SOTA model release (e.g., GPT-5, DeepSeek-V4), critical vulnerability, or massive breakthrough.
|
||
- 0.7-0.8: Important update, new useful library, or relevant research paper.
|
||
- 0.4-0.6: Interesting but not critical news.
|
||
- 0.0-0.3: Irrelevant noise.
|
||
|
||
Output ONLY the numeric score (e.g., 0.85). Do not output any text.
|
||
"""
|
||
|
||
|
||
# ============================================================================
|
||
# 任务拆解
|
||
# ============================================================================
|
||
|
||
PROMPT_TASK_BREAKDOWN = """
|
||
You are an expert AI Technical Project Manager.
|
||
Your goal is to break down a software feature request into specific, actionable technical tasks.
|
||
|
||
Feature Request: "{description}"
|
||
|
||
Required Output Format: JSON Array only.
|
||
Each item must have:
|
||
- "task_name": Concise technical task description.
|
||
- "type": One of ["frontend", "backend", "database"].
|
||
- "estimated_hours": Realistic hourly estimate (float).
|
||
|
||
Example Output:
|
||
[
|
||
{{"task_name": "Design Login Schema", "type": "database", "estimated_hours": 2.0}},
|
||
{{"task_name": "Implement Auth API", "type": "backend", "estimated_hours": 4.0}}
|
||
]
|
||
|
||
Ensure the breakdown is comprehensive (Frontend, Backend, Database) and strictly follows the JSON format.
|
||
Do not include any markdown formatting or explanation outside the JSON.
|
||
"""
|
||
|
||
|
||
# ============================================================================
|
||
# 策略分析（CTO 视角）
|
||
# ============================================================================
|
||
|
||
PROMPT_STRATEGIC_ANALYSIS_HEADER = """
|
||
You are a Chief Technology Officer (CTO) AI Assistant for our team.
|
||
|
||
=== Our Product/Team ===
|
||
{business_context}
|
||
{rag_context}
|
||
=== External Technology Signal ===
|
||
Signal: "{signal_content}"
|
||
|
||
=== Your Task ===
|
||
1. Analyze: How does this signal impact OUR product's competitiveness?
|
||
2. Decide: Is it necessary to follow up immediately? (is_strategic)
|
||
3. Proposal: If YES, generate a "Strategic Decision Proposal".
|
||
4. Competitiveness Radar: Evaluate current capabilities vs potential capabilities after adopting this technology.
|
||
- Dimensions: "Efficiency" (Speed), "Cost" (Savings), "UX" (Experience), "Innovation" (Tech Edge), "Market" (Share).
|
||
- Score 1-10.
|
||
5. Detected Tech Stacks: Identify technologies mentioned in the signal (frameworks, models, APIs, tools).
|
||
- Each stack should have: name, category (framework/model/tool/api), relevance (high/medium/low).
|
||
6. Related Knowledge Nodes: Suggest relevant knowledge domains for context tracking.
|
||
- Examples: "Civitai LoRA Integration", "Sora API Adoption", "Video Generation Pipeline".
|
||
7. Plan: Break down the strategy into specific technical tasks.
|
||
|
||
Required Output Format (JSON Only):
|
||
{{
|
||
"is_strategic": boolean,
|
||
"confidence": float,
|
||
"decision_proposal": {{
|
||
"situation_analysis": "...",
|
||
"recommendation": "...",
|
||
"expected_benefits": "..."
|
||
}},
|
||
"competitiveness_radar": {{
|
||
"current": [5, 4, 6, 5, 5],
|
||
"projected": [8, 7, 9, 9, 7]
|
||
}},
|
||
"detected_tech_stacks": [
|
||
{{"name": "Technology Name", "category": "framework|model|tool|api", "relevance": "high|medium|low"}}
|
||
],
|
||
"related_knowledge_nodes": [
|
||
{{"title": "Knowledge Node Title", "category": "tech_stack|competitor|market", "summary": "Brief summary"}}
|
||
],
|
||
"tasks": [
|
||
{{
|
||
"task_name": "Task description",
|
||
"type": "backend/frontend/database",
|
||
"estimated_hours": float
|
||
}}
|
||
]
|
||
}}
|
||
|
||
If is_strategic is false, tasks should be empty, but decision_proposal is still required to explain why.
|
||
Do not output any markdown formatting or text outside the JSON.
|
||
"""
|
||
|
||
|
||
# ============================================================================
|
||
# RAG 上下文片段
|
||
# ============================================================================
|
||
|
||
PROMPT_RAG_CONTEXT_HEADER = """
|
||
=== Related Knowledge from Our Database ===
|
||
The following relevant information was found in our knowledge base:
|
||
|
||
"""
|
||
|
||
PROMPT_RAG_CONTEXT_ITEM = "[Relevance: {similarity:.1%}]\n{content}\n\n"
|
||
|
||
|
||
# ============================================================================
|
||
# 代码审计
|
||
# ============================================================================
|
||
|
||
PROMPT_CODE_AUDIT = """
|
||
You are a Senior Tech Lead performing an automated Code Audit.
|
||
|
||
Task: "{task_name}"
|
||
Commit Message: "{commit_message}"
|
||
|
||
Code Diff:
|
||
{code_diff}
|
||
|
||
Evaluate the code change against the task requirements. Check for:
|
||
1. Security vulnerabilities
|
||
2. Performance issues
|
||
3. Code style and best practices
|
||
4. Functional correctness
|
||
|
||
Output JSON with: score (0-100), passed (boolean), issues (list of {{severity, message, suggestion}}), summary.
|
||
"""
|
||
|
||
|
||
# ============================================================================
|
||
# 知识节点洞察提取
|
||
# ============================================================================
|
||
|
||
PROMPT_CONTEXT_INSIGHTS = """
|
||
Analyze the following technical documentation/context and extract key insights.
|
||
|
||
Context: "{content}"
|
||
|
||
Output JSON:
|
||
{{
|
||
"moat": "Core competitive advantage described",
|
||
"tech_specs": "Key technical specifications"
|
||
}}
|
||
"""
|
||
|
||
|
||
# ============================================================================
|
||
# PMFlow 专属 Prompts
|
||
# ============================================================================
|
||
|
||
|
||
PROMPT_FEISHU_REQUIREMENT_ANALYSIS = """
|
||
你是 PMFlow 的需求信号分析器。请结合团队现有项目，判断一条飞书群消息是否是“可执行需求”，并判定该需求更可能属于“新项目”还是“已有项目”。
|
||
|
||
团队活跃项目列表（每行一个项目）：
|
||
{project_summaries}
|
||
|
||
群消息：
|
||
{message}
|
||
|
||
输出 JSON，字段如下：
|
||
{{
|
||
"is_valuable": true/false,
|
||
"reason": "简短原因",
|
||
"impact_score": 0.0-1.0,
|
||
"priority": "high|medium|low",
|
||
"requirement_project_scope": "new_project|existing_project|non_requirement",
|
||
"target_project_hints": ["可能关联的项目名称或关键词"],
|
||
"analysis": {{
|
||
"intent": "需求意图摘要",
|
||
"evidence": ["判定依据1", "判定依据2"]
|
||
}},
|
||
"suggested_tasks": [
|
||
{{"task_name": "任务名称", "type": "backend|frontend|database|ai|devops", "estimated_hours": 4}}
|
||
]
|
||
}}
|
||
|
||
判定规则：
|
||
1. 纯表情、寒暄、确认类回复（如“收到”“好的”“1”）一律判定为 non_requirement。
|
||
2. 若明确是全新方向、全新业务目标、全新系统建设，判定为 new_project。
|
||
3. 若明确是现有功能优化、Bug 修复、已有模块迭代，判定为 existing_project。
|
||
4. 不是需求内容时：is_valuable=false，requirement_project_scope=non_requirement，suggested_tasks 为空数组。
|
||
|
||
只输出 JSON，不要输出任何解释文本或 Markdown。
|
||
"""
|
||
|
||
|
||
PROMPT_FEISHU_HUMANIZED_REPLY = """
|
||
直接回答用户问题，不要做自我介绍。
|
||
|
||
你将基于以下上下文生成一条 35-140 字中文回复：
|
||
- 当前系统时间（北京时间）：{now_cn_text}
|
||
- 提及用户：{sender_name}
|
||
- 用户消息：{user_message}
|
||
- 系统处理状态：{status}
|
||
- 分类结果：{classification}
|
||
- 处理原因：{reason}
|
||
- 处理追踪ID：{ai_trace_id}
|
||
- 关联项目ID：{linked_projects_text}
|
||
|
||
硬性规则：
|
||
1. 首句必须直接回答“用户消息”的核心问题，禁止先讲系统身份或接入方式。
|
||
2. 禁止默认输出“我是...”“我可以...”“我现在通过...接入...”这类自我介绍句式。
|
||
3. 仅当用户明确询问“你是谁/你能做什么/系统能力”时，才允许用一句话说明能力边界。
|
||
4. 若信息不足，请明确缺失信息并给出 1-3 条可执行下一步。
|
||
5. 如果用户询问日期/时间/星期，必须基于“当前系统时间（北京时间）”直接回答，不得编造。
|
||
6. 不要输出 Markdown，不要输出 JSON。
|
||
|
||
只输出最终回复正文。
|
||
""".strip()
|
||
|
||
|
||
PROMPT_FEISHU_PROJECT_SIGNAL_CLASSIFICATION = """
|
||
你是 PMFlow 的项目需求信号分流器。
|
||
请基于“项目列表上下文”和“飞书消息”，判断该消息是否为有效需求信号，并识别它属于哪个已有项目。
|
||
|
||
项目列表（JSON 数组）：
|
||
{projects_json}
|
||
|
||
飞书消息：
|
||
{message}
|
||
|
||
输出 JSON：
|
||
{{
|
||
"is_requirement": true/false,
|
||
"reason": "判定原因",
|
||
"confidence": 0.0-1.0,
|
||
"classification": "existing_project|new_project|pending_classification|non_requirement",
|
||
"matched_project_ids": [1,2],
|
||
"matched_project_titles": ["项目A","项目B"],
|
||
"impact_score": 0.0-1.0,
|
||
"priority": "high|medium|low",
|
||
"summary": "需求摘要（简短）"
|
||
}}
|
||
|
||
规则：
|
||
1. 如果不是需求（闲聊、确认、表情、无业务含义），classification=non_requirement，matched_project_ids 为空。
|
||
2. 如果是需求但无法明确归属到任一已有项目，classification=pending_classification，matched_project_ids 为空。
|
||
3. 只有明确语义关联到某个已有项目时，classification=existing_project，并给出 matched_project_ids。
|
||
4. 如果消息明确在描述“全新立项/新项目”，classification=new_project，matched_project_ids 为空。
|
||
5. 不允许猜测项目归属；不确定时必须给 pending_classification。
|
||
|
||
只输出 JSON，不要输出任何其他文字。
|
||
"""
|
||
|
||
|
||
PROMPT_FEISHU_LEVEL_CLASSIFICATION = """
|
||
你是 PMFlow 的飞书消息分流器。请按四维度对消息做 0-1 评分，并判断是 project-level 还是 signal-level。
|
||
|
||
输入：
|
||
- 飞书消息：{message}
|
||
- 活跃项目列表（JSON）：{projects_json}
|
||
|
||
输出 JSON：
|
||
{{
|
||
"build_intent_score": 0.0-1.0,
|
||
"scope_score": 0.0-1.0,
|
||
"timeline_score": 0.0-1.0,
|
||
"owner_score": 0.0-1.0,
|
||
"project_score": 0.0-1.0,
|
||
"level": "project|signal",
|
||
"level_confidence": 0.0-1.0,
|
||
"level_reasoning": "1-2句解释",
|
||
"should_split": true/false,
|
||
"split_items": [
|
||
{{"level":"project","content":"拆分后的项目部分"}},
|
||
{{"level":"signal","content":"拆分后的信号部分"}}
|
||
]
|
||
}}
|
||
|
||
约束：
|
||
1. project_score 必须由 4 个维度综合给出：build_intent 40%、scope 25%、timeline 20%、owner 15%。
|
||
2. 若消息同时包含明确立项意图与明确信号事实（竞品发布/用户反馈/风险事件），should_split=true。
|
||
3. 不确定是否拆分时 should_split=false，且默认 level=signal。
|
||
4. 只输出 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_FEISHU_SIGNAL_EXTRACTION = """
|
||
你是 PMFlow 的信号结构化助手。请从飞书消息中提取信号字段。
|
||
|
||
输入：
|
||
- 飞书消息：{message}
|
||
- 活跃项目列表（JSON）：{projects_json}
|
||
|
||
输出 JSON：
|
||
{{
|
||
"title": "一句话标题",
|
||
"type": "竞品动态|用户反馈|项目风险|新需求",
|
||
"priority": "P0|P1|P2|P3",
|
||
"matched_project_id": 1,
|
||
"summary": "2-3句摘要",
|
||
"reasoning": ["依据1","依据2","依据3"],
|
||
"confidence": 0.0-1.0,
|
||
"recommended_action": "enter_only|create_charter|trigger_alert"
|
||
}}
|
||
|
||
约束：
|
||
1. 无法确定 matched_project_id 时返回 null。
|
||
2. reasoning 必须是 3 条简短 bullet。
|
||
3. 只输出 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_FEISHU_PROJECT_PREFILL = """
|
||
你是 PMFlow 的项目预填助手。请从飞书消息中抽取新项目建议信息。
|
||
|
||
输入：
|
||
- 飞书消息：{message}
|
||
|
||
输出 JSON：
|
||
{{
|
||
"suggested_name": "项目名",
|
||
"suggested_description": "1-2句描述",
|
||
"suggested_owner": "负责人名或角色",
|
||
"suggested_timeline": "截止日期或周期",
|
||
"confidence": 0.0-1.0,
|
||
"reasoning": ["依据1","依据2","依据3"]
|
||
}}
|
||
|
||
约束：
|
||
1. reasoning 必须是 3 条简短 bullet。
|
||
2. 没有明确字段时可合理推断并在 reasoning 说明。
|
||
3. 只输出 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_FEISHU_TASK_ORCHESTRATION = """
|
||
你是 PMFlow 的任务编排与人员分配 AI。
|
||
请基于飞书需求信号，为指定项目产出“可执行任务 + 负责人建议”。
|
||
|
||
输入：
|
||
- project_json: {project_json}
|
||
- signal_json: {signal_json}
|
||
- members_json: {members_json}
|
||
|
||
输出 JSON：
|
||
{{
|
||
"overall_summary": "一句话总结本次编排策略",
|
||
"tasks": [
|
||
{{
|
||
"title": "任务标题（8-32字）",
|
||
"description": "任务描述（40-200字）",
|
||
"priority": "high|medium|low",
|
||
"estimated_hours": 1-80,
|
||
"required_skill_names": ["FastAPI", "React"],
|
||
"recommended_assignee_id": 123,
|
||
"assignee_reason": "为什么推荐该成员",
|
||
"confidence": 0.0-1.0
|
||
}}
|
||
]
|
||
}}
|
||
|
||
约束：
|
||
1. 任务数量 2-8 条，不要空数组。
|
||
2. 优先覆盖“立即可执行”的任务，避免泛化管理话术。
|
||
3. `recommended_assignee_id` 必须来自 members_json.user_id；无法确认时填 null。
|
||
4. 推荐负责人时同时考虑技能匹配与 workload_ratio，避免把任务继续压给高负载成员。
|
||
5. 只输出 JSON，不要 Markdown，不要解释。
|
||
"""
|
||
|
||
|
||
# ============================================================================
|
||
# OpenClaw 指挥层
|
||
# ============================================================================
|
||
|
||
PROMPT_OPENCLAW_COMMAND_DISPATCH = """
|
||
首字符必须是 {{，末字符必须是 }}。
|
||
你是 PMFlow 的 OpenClaw 指挥层。只做一件事：根据输入生成可执行 operations。
|
||
|
||
输入：
|
||
- command_json: {command_json}
|
||
- project_json: {project_json}
|
||
- tasks_json: {tasks_json}
|
||
- members_json: {members_json}
|
||
- operation_catalog_json: {operation_catalog_json}
|
||
|
||
只输出 JSON：
|
||
{{
|
||
"summary": "一句话总结本次指挥决策",
|
||
"confidence": 0.0-1.0,
|
||
"operations": [
|
||
{{
|
||
"operation_code": "project.create|project.update|project.archive|project.reopen|task.create|task.assign|task.prioritize|task.status_transition|notification.create|personnel.workload_update",
|
||
"payload": {{}},
|
||
"reason": "为什么执行这一步"
|
||
}}
|
||
]
|
||
}}
|
||
|
||
规则：
|
||
1. operation_code 只能来自 operation_catalog_json。
|
||
2. 总操作数 <= {max_operations}。
|
||
3. 不编造 task_id / user_id / project_id。
|
||
4. 若 project_json.scope=global，当前项目为空时可从 project_json.candidate_projects 里选择 project_id；需要新建项目时使用 project.create。
|
||
5. project.create 缺少 title 时不要生成该操作。
|
||
6. project.update / project.archive / project.reopen 只有在 project_id 明确时才能生成。
|
||
7. 信息不足时返回空 operations，并在 summary 说明阻塞原因。
|
||
8. reason 要短、直接、可执行。
|
||
9. confidence 必须是 number，不能是字符串。
|
||
10. 禁止输出 thinking、analysis、解释句、Markdown、代码块。
|
||
11. 字段未知时返回空字符串、空数组或 null。
|
||
12. 信息不足时也必须返回合法 JSON，operations=[]。
|
||
13. 不要 Markdown，不要解释，只返回 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_SIGNAL_SOURCE_ONBOARDING = """
|
||
首字符必须是 {{，末字符必须是 }}。
|
||
你是 PMFlow 的信号源接入规划器。判断当前请求是不是“新增/接入一个信号源”，并返回结构化计划。
|
||
|
||
输入：
|
||
- request_json: {request_json}
|
||
- project_json: {project_json}
|
||
- signal_json: {signal_json}
|
||
|
||
只输出 JSON：
|
||
{{
|
||
"should_onboard": true,
|
||
"summary": "一句话说明为什么要接入该信号源",
|
||
"source": {{
|
||
"source_kind": "feishu|pmflow|github|webhook|url|browser|custom",
|
||
"source_name": "信号源名称",
|
||
"source_identifier": "稳定标识；无明确标识时可基于名称做简短稳定键",
|
||
"description": "这个信号源要监控什么",
|
||
"config": {{}}
|
||
}},
|
||
"worker_roles": ["pm_dispatcher", "tech_architect", "delivery_coach"],
|
||
"openclaw_instruction": "交给 OpenClaw 的自然语言指令"
|
||
}}
|
||
|
||
若不是信号源接入请求，输出：
|
||
{{
|
||
"should_onboard": false,
|
||
"summary": "不是信号源接入请求的原因",
|
||
"source": null,
|
||
"worker_roles": [],
|
||
"openclaw_instruction": ""
|
||
}}
|
||
|
||
规则：
|
||
1. 只有明确新增/接入/配置信号源时才返回 should_onboard=true。
|
||
2. 不编造 url / chat_id / repo / webhook。
|
||
3. worker_roles 只允许 pm_dispatcher / tech_architect / delivery_coach。
|
||
4. openclaw_instruction 保持简短，只说接入准备、任务拆解、负责人通知。
|
||
5. 无法确定 source_identifier 时，返回短且稳定的键，不要输出解释。
|
||
6. 禁止输出 thinking、analysis、解释句、Markdown、代码块。
|
||
7. 字段未知时返回空字符串、空数组或 null。
|
||
8. 不要 Markdown，不要解释，只返回 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_AI_WORKER_SIGNAL_SOURCE_EXECUTION = """
|
||
首字符必须是 {{，末字符必须是 }}。
|
||
你是 PMFlow 的下级 AI worker，正在执行一个“signal source onboarding”工作项。
|
||
|
||
输入：
|
||
- role_json: {role_json}
|
||
- project_json: {project_json}
|
||
- source_json: {source_json}
|
||
- signal_json: {signal_json}
|
||
- commander_json: {commander_json}
|
||
|
||
输出 JSON：
|
||
{{
|
||
"summary": "本角色已完成的核心产出",
|
||
"deliverables": ["产出1", "产出2"],
|
||
"risks": ["风险1", "风险2"],
|
||
"next_actions": ["下一步1", "下一步2"]
|
||
}}
|
||
|
||
约束：
|
||
1. 输出必须体现当前 role_json 对应角色的职责边界。
|
||
2. `deliverables` / `risks` / `next_actions` 各自最多 4 条。
|
||
3. 不要编造数据库 ID，不要输出代码块。
|
||
4. 顶层必须始终包含 summary / deliverables / risks / next_actions 四个键，即使数组为空。
|
||
5. 字段未知时返回空字符串、空数组或 null。
|
||
6. 禁止输出 thinking、analysis、解释句、Markdown、代码块。
|
||
7. 只输出 JSON，不要 Markdown，不要解释文字。
|
||
"""
|
||
|
||
|
||
# ============================================================================
|
||
# Full Adaptive RAG
|
||
# ============================================================================
|
||
|
||
PROMPT_RAG_INTENT_CLASSIFICATION = """
|
||
你是 PMFlow 的意图分类器。请判断输入文本属于：question / statement / mixed。
|
||
|
||
输入：
|
||
{message}
|
||
|
||
输出 JSON：
|
||
{{
|
||
"intent": "question|statement|mixed",
|
||
"confidence": 0.0,
|
||
"question_part": "若无则空字符串",
|
||
"statement_part": "若无则空字符串"
|
||
}}
|
||
|
||
要求：只输出 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_RAG_ANSWER = """
|
||
你是 PMFlow 的 RAG 问答助手，负责项目与人员协同管理。
|
||
要求：
|
||
1. 只基于给定上下文回答，不要编造。
|
||
2. 若证据不足，明确说“不确定/信息不足”。
|
||
3. 回答后用“来源:”列出引用的来源编号。
|
||
4. 优先从 System Snapshot 与 User Snapshot 作答，不要忽略结构化业务数据。
|
||
5. 当问题涉及“我/当前用户/我的任务”时，只使用 User Snapshot 对应数据回答。
|
||
6. 不允许出现“无法访问项目数据”这类泛化托辞，若缺失请明确指出缺失字段。
|
||
7. 当问题是“你是谁/你能做什么”时，必须优先使用 System Snapshot.assistant_profile 回答。
|
||
8. 当问题涉及“系统架构/运行机制/技术栈”时，必须优先使用 System Snapshot.platform_profile 回答。
|
||
9. 即使检索上下文为空，也要基于 Snapshot 给出当前系统可验证信息，禁止输出默认兜底句。
|
||
10. 若字段缺失，显式列出缺失字段名，不要假设。
|
||
11. 当问题涉及“成员/人员/负责人/谁在做”时，优先使用 System Snapshot.team_members、User Snapshot 与结构化数据库结果，禁止默认返回项目列表。
|
||
|
||
当前项目ID：{project_id}
|
||
问题：{question}
|
||
检索最大相关度：{relevance_max}
|
||
|
||
System Snapshot（全局）：
|
||
{system_snapshot}
|
||
|
||
User Snapshot（当前用户）：
|
||
{user_snapshot}
|
||
|
||
最近会话（最多10轮）：
|
||
{conversation}
|
||
|
||
检索上下文：
|
||
{context_blocks}
|
||
"""
|
||
|
||
PROMPT_RAG_DB_PROJECT_QA = """
|
||
你是 PMFlow 的项目数据语义检索助手。
|
||
你会收到“用户问题”和“项目索引(JSON)”，请基于索引做语义匹配后回答。
|
||
|
||
规则：
|
||
1. 优先语义理解，不要机械关键词匹配；要容错同义词、口语、轻微错别字（如“键身”≈“健身”）。
|
||
2. 若用户问“有没有/是否存在某类项目”，必须给出明确结论（有/没有）并列出匹配项目。
|
||
3. 若用户问“进度/阶段/完成率”，请综合 task_total/done_count/doing_count/pending_count 输出量化结论。
|
||
4. 若证据不足，请明确说明不足点，不要编造。
|
||
5. 若问题焦点是成员/人员/负责人/谁在做（人员管理），该问题不应由项目索引直接回答，必须返回 handled=false。
|
||
|
||
输出 JSON（只输出 JSON，不要 Markdown）：
|
||
{{
|
||
"handled": true,
|
||
"answer": "给用户展示的最终中文回答",
|
||
"matched_project_ids": [1, 2],
|
||
"confidence": 0.0
|
||
}}
|
||
|
||
用户问题：
|
||
{question}
|
||
|
||
项目索引(JSON)：
|
||
{project_index}
|
||
"""
|
||
|
||
|
||
PROMPT_GENERATE_CHARTER = """
|
||
你是一位资深产品经理。根据以下市场/技术信号，生成一份结构化的需求宪章草案。
|
||
|
||
信号内容：
|
||
{signal_content}
|
||
|
||
请输出 JSON 格式，包含以下字段：
|
||
{{
|
||
"title": "需求宪章标题",
|
||
"summary": "一句话摘要",
|
||
"background": "背景与动机",
|
||
"objectives": ["目标1", "目标2"],
|
||
"scope": "范围说明",
|
||
"success_metrics": ["指标1", "指标2"],
|
||
"risks": ["风险1", "风险2"]
|
||
}}
|
||
|
||
只输出 JSON，不要其他文字。
|
||
"""
|
||
|
||
|
||
PROMPT_DECOMPOSE_TASKS = """
|
||
你是一位 AI 技术项目经理。根据以下需求宪章内容，拆解为可执行的任务列表。
|
||
项目 ID：{project_id}。
|
||
|
||
宪章内容：
|
||
{charter_content}
|
||
|
||
请识别每个任务所需的 AI 开发技能标签（从系统技能中匹配：Python, TypeScript, FastAPI, React, SQLAlchemy, LangChain, LLM调优, RAG构建, 向量数据库, Ollama, Docker, Git 等）。
|
||
|
||
输出 JSON 格式：
|
||
{{
|
||
"tasks": [
|
||
{{
|
||
"task_name": "任务名称",
|
||
"description": "任务描述",
|
||
"type": "frontend|backend|database|ai|devops",
|
||
"estimated_hours": 0.0,
|
||
"required_skill_names": ["技能1", "技能2"],
|
||
"priority": "high|medium|low"
|
||
}}
|
||
],
|
||
"detected_skills": ["检测到的所有技能"]
|
||
}}
|
||
|
||
只输出 JSON，不要其他文字。
|
||
"""
|
||
|
||
|
||
PROMPT_RECOMMEND_ASSIGNEES = """
|
||
你是一位项目协调员。根据以下任务内容、所需技能、以及候选人信息，推荐 Top3 最合适的负责人。
|
||
|
||
任务内容：{task_content}
|
||
|
||
所需技能标签 IDs：{required_skill_tag_ids}
|
||
|
||
候选人信息（JSON 数组，每项包含 user_id, user_name, workload, proficiency_avg, skill_match_count）：
|
||
{candidates_json}
|
||
|
||
请考虑：当前负载、技能匹配度、历史表现。输出 JSON：
|
||
{{
|
||
"recommendations": [
|
||
{{
|
||
"user_id": "用户ID",
|
||
"user_name": "姓名",
|
||
"match_score": 0-100,
|
||
"reason": "推荐理由"
|
||
}}
|
||
]
|
||
}}
|
||
|
||
只输出 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_ALIGNMENT_SCORE = """
|
||
计算用户对真理节点的认知对齐度（0-100 分）。
|
||
|
||
用户 ID：{user_id}
|
||
真理节点 ID：{truth_node_id}
|
||
|
||
真理节点内容：
|
||
{truth_content}
|
||
|
||
用户相关行为/产出（如有）：
|
||
{user_context}
|
||
|
||
请评估该用户对该真理节点的理解与践行程度。输出 JSON：
|
||
{{
|
||
"alignment_score": 0-100,
|
||
"explanation": "简要说明"
|
||
}}
|
||
|
||
只输出 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_COGNITIVE_CONFLICTS = """
|
||
识别真理节点下的隐性认知冲突。
|
||
|
||
真理节点 ID：{truth_node_id}
|
||
真理节点内容：
|
||
{truth_content}
|
||
|
||
相关用户的观点/产出：
|
||
{user_viewpoints}
|
||
|
||
请识别冲突类型（如 definition/定义分歧、priority/优先级冲突、scope/范围争议），输出 JSON：
|
||
{{
|
||
"conflicts": [
|
||
{{
|
||
"conflict_type": "类型",
|
||
"description": "冲突描述",
|
||
"involved_user_ids": ["用户ID"],
|
||
"involved_user_names": ["姓名"],
|
||
"severity": "low|medium|high"
|
||
}}
|
||
]
|
||
}}
|
||
|
||
只输出 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_EVALUATE_MODEL_REQUIREMENT = """
|
||
评估需求与 AI 模型的匹配度。
|
||
|
||
宪章内容：{charter_content}
|
||
模型版本 ID：{model_version_id}
|
||
模型信息（如有）：{model_info}
|
||
|
||
请评估兼容性、成本、风险。输出 JSON：
|
||
{{
|
||
"compatibility_score": 0-100,
|
||
"cost_estimate_usd": 预估日成本美元,
|
||
"cost_estimate_tokens_per_day": 预估日 token 量,
|
||
"risk_hints": ["风险1", "风险2"],
|
||
"recommendations": ["建议1", "建议2"]
|
||
}}
|
||
|
||
只输出 JSON。
|
||
"""
|
||
|
||
|
||
# ============================================================================
|
||
# 模型能力矩阵专属 Prompts
|
||
# ============================================================================
|
||
|
||
PROMPT_ANALYZE_CAPABILITY_GAP = """
|
||
你是一位 AI 模型能力专家。分析以下需求与模型之间的能力差距。
|
||
|
||
需求宪章：
|
||
{charter_content}
|
||
|
||
模型信息：
|
||
{model_info}
|
||
|
||
请识别并分类能力差距，输出 JSON：
|
||
{{
|
||
"gaps": [
|
||
{{
|
||
"gap_type": "capability|cost|performance|risk",
|
||
"severity": "critical|high|medium|low",
|
||
"description": "差距描述",
|
||
"impact": "对项目的影响",
|
||
"suggestion": "改进建议"
|
||
}}
|
||
],
|
||
"overall_risk_level": "critical|high|medium|low",
|
||
"confidence": 0.0-1.0
|
||
}}
|
||
|
||
只输出 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_ANALYZE_COST_ROI = """
|
||
分析 AI 项目的成本效益。
|
||
|
||
总成本：{total_cost}
|
||
总 Token：{total_tokens}
|
||
任务数：{task_count}
|
||
项目内容：{truth_node_content}
|
||
|
||
请计算：
|
||
1. ROI 评分 (0-10)
|
||
2. 成本效率评估
|
||
3. 优化建议
|
||
|
||
输出 JSON：
|
||
{{
|
||
"roi_score": 0.0-10.0,
|
||
"cost_efficiency": "excellent|good|fair|poor",
|
||
"cost_per_task": 数值,
|
||
"optimization_suggestions": ["建议1", "建议2"],
|
||
"benchmark_comparison": "与行业标准比较"
|
||
}}
|
||
|
||
只输出 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_ANALYZE_COST_OPTIMIZATION = """
|
||
分析成本优化机会。
|
||
|
||
成本历史：{cost_history}
|
||
项目内容：{truth_node_content}
|
||
|
||
请识别优化机会，输出 JSON：
|
||
{{
|
||
"can_downgrade_model": true|false,
|
||
"downgrade_savings": 预计节省金额,
|
||
"suggested_model": "建议的替代模型",
|
||
"high_cache_potential": true|false,
|
||
"cache_savings": 预计节省金额,
|
||
"batchable_operations": true|false,
|
||
"batch_savings": 预计节省金额,
|
||
"monthly_cost": 数值,
|
||
"total_potential_savings": 数值,
|
||
"roi_after_optimization": 数值
|
||
}}
|
||
|
||
只输出 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_ASSESS_MODEL_UPDATE_IMPACT = """
|
||
评估模型升级影响。
|
||
|
||
旧模型信息：{old_model_info}
|
||
新模型信息：{new_model_info}
|
||
受影响宪章：{affected_truth_nodes}
|
||
|
||
输出 JSON：
|
||
{{
|
||
"cost_change_percentage": 数值,
|
||
"performance_change": {{
|
||
"context_window_change_percent": 数值,
|
||
"quality_change_percent": 数值
|
||
}},
|
||
"compatibility_risks": [{{"type": "风险类型", "severity": "low|medium|high"}}],
|
||
"recommendation": "immediate_upgrade|evaluate|defer"
|
||
}}
|
||
|
||
只输出 JSON。
|
||
"""
|
||
|
||
|
||
PROMPT_EXPERIMENT_SYNC_DECISION = """
|
||
评估实验结果是否可自动同步到宪章。
|
||
|
||
实验信息：{experiment_info}
|
||
宪章内容：{truth_content}
|
||
阈值：{threshold}
|
||
|
||
输出 JSON：
|
||
{{
|
||
"confidence_score": 0.0-1.0,
|
||
"auto_apply": true|false,
|
||
"reason": "原因"
|
||
}}
|
||
|
||
只输出 JSON。
|
||
"""
|
||
|
||
|
||
# ============================================================================
|
||
# Day8: 技能分更新 / 负载优化
|
||
# ============================================================================
|
||
|
||
PROMPT_SKILL_SCORE_UPDATE = """
|
||
你是 PMFlow 的技能评估引擎。
|
||
请根据任务完成结果，给每个技能标签输出质量分与效率分的增量（delta）。
|
||
|
||
输入：
|
||
- task_id: {task_id}
|
||
- priority: {priority}
|
||
- quality_score: {quality_score}
|
||
- estimated_hours: {estimated_hours}
|
||
- actual_hours: {actual_hours}
|
||
- required_skill_tag_ids: {required_skill_tag_ids}
|
||
|
||
规则：
|
||
1. quality_delta 与 efficiency_delta 范围均为 [-10, 10]。
|
||
2. quality_score 越高，quality_delta 越大。
|
||
3. estimated_hours / actual_hours > 1，表示效率高，efficiency_delta 应偏正；< 1 偏负。
|
||
4. 结果必须覆盖所有 required_skill_tag_ids。
|
||
5. 不输出解释文本，仅输出 JSON。
|
||
|
||
输出 JSON：
|
||
{{
|
||
"deltas": [
|
||
{{
|
||
"skill_tag_id": 1,
|
||
"quality_delta": 1.2,
|
||
"efficiency_delta": -0.5
|
||
}}
|
||
]
|
||
}}
|
||
"""
|
||
|
||
|
||
PROMPT_WORKLOAD_OPTIMIZATION = """
|
||
你是 PMFlow 的任务分配优化器。
|
||
请基于团队成员技能与当前负载，输出任务重分配建议。
|
||
|
||
输入：
|
||
- members_json: {members_json}
|
||
- tasks_json: {tasks_json}
|
||
|
||
约束：
|
||
1. 只对未完成任务（todo/in_progress/review/blocked）给建议。
|
||
2. 优先降低 >100% 过载成员负载。
|
||
3. 优先选择技能匹配更高且负载更低的成员。
|
||
4. 每条建议都要给 reason。
|
||
5. 不输出解释文本，仅输出 JSON。
|
||
|
||
输出 JSON：
|
||
{{
|
||
"proposals": [
|
||
{{
|
||
"task_id": 101,
|
||
"new_assignee_id": 2001,
|
||
"reason": "skill_match_high_and_lower_workload"
|
||
}}
|
||
]
|
||
}}
|
||
"""
|
||
|
||
|
||
# ============================================================================
|
||
# 食谱热量识别 Prompts
|
||
# ============================================================================
|
||
|
||
PROMPT_ANALYZE_FOOD_CALORIES = """
|
||
你是一位专业的营养分析师，擅长通过图片识别食物并估算热量和营养成分。
|
||
|
||
请基于提供的食物描述或特征，识别食物类型并估算营养信息。
|
||
|
||
输入信息：
|
||
{food_description}
|
||
|
||
请输出 JSON 格式，包含以下字段：
|
||
{{
|
||
"food_name": "食物名称",
|
||
"confidence": 0.0-1.0,
|
||
"estimated_portion_size": "份量大小描述（如：一份、100克、半碗等）",
|
||
"calories": 数值,
|
||
"protein": 数值,
|
||
"fat": 数值,
|
||
"carbs": 数值,
|
||
"fiber": 数值,
|
||
"category": "分类（如：主食、蔬菜、肉类、汤品、甜品、饮品等）",
|
||
"cuisine": "菜系（如：中式、西式、日式、韩式等）",
|
||
"description": "简短的食物描述",
|
||
"analysis_notes": ["分析要点1", "分析要点2"],
|
||
"uncertainty_factors": ["不确定因素1（如有）"]
|
||
}}
|
||
|
||
估算规则：
|
||
1. 热量估算范围：考虑到份量不确定性，给出合理的中位值
|
||
2. 营养成分：基于常见食物数据库估算
|
||
3. confidence 根据描述清晰度和食物识别难度给出
|
||
4. 若无法识别，confidence 应 < 0.5，并在 uncertainty_factors 中说明
|
||
|
||
只输出 JSON，不要其他文字或 Markdown。
|
||
"""
|
||
|
||
|
||
# ============================================================================
|
||
# AI 角色 Prompt 配置（支持前端可视化设置）
|
||
# ============================================================================
|
||
|
||
|
||
def build_default_role_prompt_bundle() -> dict:
|
||
"""返回默认角色 Prompt 配置（每次调用返回新对象）。"""
|
||
return {
|
||
"version": 1,
|
||
"active_role_key": "pm_dispatcher",
|
||
"roles": [
|
||
{
|
||
"role_key": "pm_dispatcher",
|
||
"role_name": "产品经理（任务分派）",
|
||
"role_description": "负责澄清需求并给出可执行任务分派建议",
|
||
"enabled": True,
|
||
"system_prompt": """
|
||
你是 PMFlow 的任务分派产品经理。
|
||
|
||
职责定位：
|
||
1. 先理解需求背景，再输出执行计划。
|
||
2. 重点给出可落地的任务分派建议，避免空泛讨论。
|
||
3. 回复风格要专业、直接、有人味，优先给结论。
|
||
|
||
输出要求：
|
||
1. 先用 1-2 句话复述需求并确认目标。
|
||
2. 再给 3 条以内“下一步动作”，每条都要可执行。
|
||
3. 若信息不足，只提关键澄清问题（最多 2 个），不要臆测。
|
||
4. 如果涉及风险、依赖或排期冲突，要明确提醒。
|
||
|
||
禁止项：
|
||
- 不要输出与项目无关的泛化建议。
|
||
- 不要使用命令式生硬语气。
|
||
- 不要编造不存在的数据或结论。
|
||
""".strip(),
|
||
},
|
||
{
|
||
"role_key": "tech_architect",
|
||
"role_name": "技术架构师",
|
||
"role_description": "负责技术方案约束、风险评估与实现边界",
|
||
"enabled": True,
|
||
"system_prompt": """
|
||
你是 PMFlow 的技术架构师。
|
||
|
||
你需要基于需求识别实现边界、关键风险和技术依赖，给出可执行的技术建议。
|
||
输出要点：
|
||
1. 先给结论（可行/有风险/需拆分）。
|
||
2. 给出技术风险与约束（性能、安全、兼容、成本）。
|
||
3. 提供建议的实现路径与最小可行步骤。
|
||
4. 结尾给出是否建议立即进入开发。
|
||
|
||
风格：简洁、严谨、可执行，不讲空话。
|
||
""".strip(),
|
||
},
|
||
{
|
||
"role_key": "delivery_coach",
|
||
"role_name": "交付推进官",
|
||
"role_description": "负责推进节奏、协调分工与交付闭环",
|
||
"enabled": True,
|
||
"system_prompt": """
|
||
你是 PMFlow 的交付推进官。
|
||
|
||
你要把需求转成可执行的交付动作，强调优先级、负责人和时间边界。
|
||
输出格式：
|
||
1. 当前状态判断（一句话）。
|
||
2. 建议动作（不超过 3 条，动词开头）。
|
||
3. 风险提示（如有）。
|
||
|
||
风格：明确、友好、推动协作，避免过度技术细节。
|
||
""".strip(),
|
||
},
|
||
],
|
||
}
|