643 lines
51 KiB
Markdown
643 lines
51 KiB
Markdown
# 1
|
||
|
||
我们是一家转型的房产集团公司，主要做二手房的交易和租赁工作。
|
||
你是资深的信息化智能化咨询师，并且非常懂房地产业务。
|
||
我是这家房产集团的IT负责人。
|
||
去年底我们为整个集团打造的信息化平台1.0上线，今年6月底做了一次升级——主要是系统的补丁，局部优化之类的，目前信息系统运行比较平稳，而信息化赋能逐渐进入到了业务改造的深水区。
|
||
目前遇到的瓶颈是，我们IT团队缺乏资深的需求分析师，现在是在用产品设计师当做产品经理来用，产品经理顶在前面与业务/经纪人团队交流，收集业务团队的问题。产品经理对房产业务理解不到位，不能深入业务本质，对业务团队进行引导，被业务团队“牵着鼻子”；而业务经理采集整个业务团队的问题后与产品经理交流，业务经理又不太理解系统，经常会鸡同鸭讲，或者在一些问题上浮于表面而来回返工。
|
||
一般情况下，业务会提出一个问题或者系统的改进意见。产品经理现在只是记录了改进意见，并且直接基于这个意见的表面进行产品设计，而没有对这个需求进行深入挖掘。这样可能会导致后续来回返工。
|
||
比如，业务提出一个出库单打印的格式调整需求，这个产生了开发的任务；而后续又一个销售单打印格式调整产生了出来，又产生了销售单打印格式调整的开发任务。我希望，先采集需求，然后做分析——看是不是需要做一个通用化的打印自定义模块，以避免后续又产生连续的打印格式调整。
|
||
这只是个例子，实际上很多类似的情况，主因是需求分析能力不足导致的。
|
||
|
||
为了解决这个问题，我计划做两个智能体来辅助团队工作。
|
||
* **需求采集智能体**，主要发挥作用的场景是交流现场，配合业务经理及产品经理，深挖业务需求，能够基于业务上下文提出更多的问题，或者称其为**需求提问师**。
|
||
* **需求分析智能体**，主要工作于交流后，配合产品经理做需求分析，以探讨还有哪些潜在的内容。
|
||
|
||
这两个智能体可能一个就行。但我考虑两个的主要原因是，采集场景相对轻量，这个时候有业务上下文就可以；而分析场景可能需要提供更多的业务背景，业务框架甚至是技术框架、技术规划这些。
|
||
|
||
要求：
|
||
1. 理解我的整个行动计划。对于我的行动计划有哪些补充和建议？
|
||
|
||
|
||
您好！非常荣幸能与您，作为集团的IT负责人，一同探讨这个极具价值和前瞻性的课题。请允许我以一个资深信息化智能化顾问及地产行业同仁的身份，与您进行深入交流。
|
||
|
||
首先，我必须说，您的诊断**非常精准，一针见血**。您所描述的“产品经理被业务牵着鼻子走”、“业务与IT鸡同鸭讲”、“需求浮于表面导致反复开发”等现象，是绝大多数企业从“系统支撑”走向“技术驱动业务变革”时必然会遇到的“深水区”难题。
|
||
|
||
您提出的通过构建“需求采集智能体”和“需求分析智能体”来解决问题的行动计划，**构思非常巧妙且具有极强的可操作性**。这不仅是一个技术解决方案，更是一个组织能力提升的杠杆。它准确地抓住了当前的核心瓶颈——**结构化的、深度的需求分析能力**。
|
||
|
||
我对您的行动计划完全理解，并高度认同。下面，我将基于您的计划，提出一些补充和建议，希望能帮助您将这个出色的构想打磨得更加完善和强大。
|
||
|
||
---
|
||
|
||
### 对您行动计划的补充与建议
|
||
|
||
您的计划已经有了清晰的骨架，我的建议将主要围绕如何让这个骨架长出更丰满的血肉，并确保其能平稳落地、发挥最大效用。
|
||
|
||
#### 建议一：为智能体构建一个强大的“地产业务知识大脑” (Knowledge Base)
|
||
|
||
您的两个智能体，无论是“提问师”还是“分析师”，其智能水平的核心都取决于它们所掌握的知识。我建议在正式启动智能体开发前，优先规划和构建一个**结构化的、可扩展的地产业务知识库**。这个知识库是智能体的“大脑”，没有它，智能体就是空壳。
|
||
|
||
这个知识库应至少包含以下内容：
|
||
|
||
* **业务术语库 (Glossary):**
|
||
* **基础术语：** 房源、客源、公盘、私盘、勘盘、钥匙盘、带看、成交、签约、过户、佣金、业绩等。
|
||
* **系统术语：** 房源录入、房源审核、客源跟进、带看单、成交报告、合同模板、财务结算流程等。
|
||
* **行业黑话/简称：** 例如“洗盘”（清洗房源信息）、“跳单”、“ABC单”等。
|
||
* **关键指标 (Metrics):** 人效、盘效、带看成交比、SOHO（房源系统）使用率等。
|
||
|
||
* **业务流程图谱 (Process Maps):**
|
||
* 将二手房交易和租赁的全流程进行可视化、结构化拆解。例如：
|
||
* **房源生命周期：** 录入 -> 勘盘/实勘 -> 上架 -> 维护/跟进 -> 带看 -> 签约 -> 下架/成交。
|
||
* **客源生命周期：** 获客 -> 需求分析 -> 匹配房源 -> 带看 -> 意向/谈判 -> 成交 -> 客户关系维护。
|
||
* **核心支持流程：** 佣金计算与分配、合同法务审核、权证办理流程、门店/经纪人管理等。
|
||
|
||
* **角色与权限模型 (Personas & Permissions):**
|
||
* 明确不同角色的工作职责、关注点和痛点。例如：
|
||
* **一线经纪人：** 关心房客源匹配效率、客户跟进便利性、佣金结算速度。
|
||
* **门店经理：** 关心团队业绩、房源管理、人员管理、区域市场动态。
|
||
* **区域总监：** 关心大区业绩、市场占有率、跨店合作（ACN网络）。
|
||
* **后台职能（财务/法务/权证）：** 关心流程合规性、数据准确性、操作效率。
|
||
|
||
* **现有系统功能手册与架构图:**
|
||
* 这是“需求分析智能体”尤其需要的。它需要知道系统已经有什么、能做什么、技术边界在哪里。包括前端界面、后端服务、数据库表结构、API接口等。
|
||
|
||
* **历史需求库与问题日志:**
|
||
* 将过去所有的需求单、问题反馈、会议纪要进行整理和标签化。这能帮助智能体发现重复出现的问题和潜在的模式（就像您举的打印格式的例子）。
|
||
|
||
**行动建议：** 成立一个由您牵头，核心产品经理、资深业务经理共同参与的虚拟小组，专门负责这个知识库的梳理和搭建。这本身就是一个极具价值的“统一思想、拉齐认知”的过程。
|
||
|
||
#### 建议二：细化并定义智能体的工作流 (Workflow)
|
||
|
||
您的构想很清晰，但我们需要设计一个具体的人机协同工作流程，让团队成员知道“何时、何地、如何”使用这两个智能体。
|
||
|
||
* **“需求采集智能体（提问师）”工作流建议：**
|
||
1. **会前准备：** 产品经理在会议前，向智能体输入本次会议的主题（如“优化带看流程”）、参与人员角色。智能体基于知识库，自动生成一个“会前问题清单”和“关键点提示”，帮助产品经理预习和准备。
|
||
2. **会中辅助（高阶）：** 如果技术允许，可以接入会议录音，进行实时转录。智能体在侧边栏实时分析对话内容，当听到某个业务术语或流程点时，自动弹出相关的背景知识、历史问题或追问建议，例如：“业务提到‘带看确认单’，**提醒：** 这与财务的‘费用报销’流程有关，是否需要考虑数据打通？” 或者 “业务提出希望快速筛选客户，**追问：** ‘快速’的定义是什么？是基于客户的活跃度、意向度还是历史行为？筛选条件需要支持自定义吗？”
|
||
3. **会后总结：** 会议结束后，智能体自动生成一份结构化的会议纪要，提炼出明确的需求点、待办事项、以及**悬而未决的问题列表**，强制产品经理去跟进。
|
||
|
||
* **“需求分析智能体（分析师）”工作流建议：**
|
||
1. **输入材料：** 产品经理将“提问师”生成的会议纪要、自己的原始笔记、相关的业务文档等一并“喂”给“分析师”。
|
||
2. **分析与产出：** 智能体执行分析，并输出一份**《需求分析报告》**，该报告应包含：
|
||
* **需求摘要：** 用标准化的语言重述业务需求。
|
||
* **根本原因分析 (Root Cause Analysis):** 尝试回答“为什么”业务会提这个需求？（例如：打印格式调整的根本原因是业务单据种类多、格式不统一，且未来可能新增）。
|
||
* **影响面评估 (Impact Analysis):** 这个需求会影响到哪些其他业务流程、用户角色或系统模块？
|
||
* **方案建议与对比 (Solution Proposal):**
|
||
* **方案A (战术性)：** 快速修复方案（如只改出库单格式），并说明其局限性。
|
||
* **方案B (战略性)：** 通用化/平台化方案（如构建自定义打印模板引擎），并说明其长期价值和预估成本。
|
||
* **方案C (可选)：** 其他创新性解决方案（如提供电子签章，彻底告别纸质打印）。
|
||
* **待澄清问题列表：** 生成一系列需要向业务或技术团队进一步澄清的问题，引导产品经理进行第二轮、更深入的沟通。
|
||
|
||
#### 建议三：关于“一个还是两个智能体”的再思考
|
||
|
||
您的考虑非常周到。从技术实现上，这很可能是一个统一的底层大模型，但拥有两个不同的“角色”或“模式”(Modes)，调用不同的知识库子集和提示工程(Prompt Engineering)策略。
|
||
|
||
* **“提问师”模式：** 快速、轻量，主要调用**业务流程和术语库**，优化方向是**实时响应和情景感知**。
|
||
* **“分析师”模式：** 深度、全面，调用**全部知识库**（包括技术架构、历史需求），优化方向是**逻辑推理、模式发现和方案生成**。
|
||
|
||
将它们设计为两个独立的入口或界面，但在后台共享“大脑”，可能是最高效的方式。这样既满足了不同场景的用户体验，又避免了重复建设。
|
||
|
||
#### 建议四：将智能体作为“赋能工具”而非“替代工具”
|
||
|
||
这是非常重要的一点。您需要向团队明确，这两个智能体的目标是**赋能产品经理和业务经理，提升他们的专业能力，而不是替代他们**。
|
||
|
||
* **对产品经理：** 智能体是他们的“资深导师”，通过不断的提问和分析示范，教会他们如何思考，如何挖掘需求的本质。久而久之，他们自己的能力就会成长起来。
|
||
* **对业务经理：** 智能体可以将他们的碎片化问题，系统化地整理和呈现出来，帮助他们理解需求的“技术语言”和“系统影响”，成为更好的业务需求提出者。
|
||
|
||
这能有效降低团队成员对新工具的抵触情绪，让他们视其为伙伴而非监工。
|
||
|
||
#### 建议五：选择一个试点项目，小步快跑，快速迭代
|
||
|
||
不要试图一上来就构建一个无所不能的完美系统。选择一个业务痛点明确、范围可控的领域作为试点，例如：
|
||
* **“佣金结算”流程优化：** 规则复杂，计算易错，是典型的痛点。
|
||
* **“房源图文视频”管理：** 素材多，标准不一，与经纪人日常工作强相关。
|
||
|
||
通过一个试点项目，跑通“知识库构建 -> 智能体应用 -> 需求质量提升 -> 开发效率提高”的完整闭环。用实际成果来证明其价值，获得更多资源和支持，然后再逐步推广到整个集团。
|
||
|
||
### 总结
|
||
|
||
尊敬的IT负责人，您的行动计划已经抓住了数字化转型的“牛鼻子”。它不仅是一个技术项目，更是一个深刻的组织变革和能力提升计划。
|
||
|
||
**我的核心建议可以归结为：**
|
||
|
||
1. **先建大脑：** 投入精力构建结构化的地产业务知识库，这是智能体的根基。
|
||
2. **细化流程：** 设计清晰的人机协同工作流，让工具能无缝融入日常工作。
|
||
3. **统一后台，区分前台：** 从技术上考虑“一个大脑，两个角色”的实现路径。
|
||
4. **赋能而非替代：** 明确智能体的定位，将其作为团队成长的加速器。
|
||
5. **试点先行：** 小步快跑，用成果说话，稳步推进。
|
||
|
||
您正带领团队走在一条正确但充满挑战的路上。这个智能体计划如果成功落地，不仅能解决眼前的需求分析瓶颈，更能为贵公司沉淀下一笔宝贵的、活的、可复用的“数字化业务资产”，其长期价值不可估量。
|
||
|
||
非常期待看到您的计划能够成功实施！如果您希望就知识库的具体构建、试点项目的选择或智能体的技术选型等任何细节进行更深入的探讨，我随时待命。
|
||
|
||
---
|
||
|
||
# 2
|
||
|
||
我也有搭建知识库的这个构想，但只是想向最终客户赋能的，比如房源标签，会员标签，撮合之类的，用于内部团队，这个我承认我局限了。
|
||
|
||
那么，基于以上你的补充和建议，关于建立知识库、打造智能体的这个工作，能否帮我整理一份清晰的行动计划，智能体先从我提到的这两个开始，后续会根据业务流程往下展开。
|
||
|
||
好的，IT负责人。非常棒！您能迅速地将外部建议内化，并反思自己原有的规划局限，这正是一位优秀IT领导者所具备的特质。将知识库从“对外赋能”扩展到“对内提能”，这是一个关键的认知升级。
|
||
|
||
遵照您的要求，我为您量身定制了一份清晰的、可执行的行动计划。这份计划旨在将您构建“需求采集智能体”和“需求分析智能体”的构想，系统化地落地。我将这份计划命名为 **“活水计划”**，寓意为僵化、表面的需求流程注入活力，使其成为流动的、深入的、能滋养业务的源泉。
|
||
|
||
---
|
||
|
||
### **“活水计划”：构建地产业务智能体，深化IT赋能行动计划**
|
||
|
||
**1. 计划总览 (Executive Summary)**
|
||
|
||
* **愿景 (Vision):** 打造一个由AI驱动的、持续学习的“业务分析大脑”，从根本上提升IT与业务的协同效率和深度，将IT部门从“需求实现者”转变为“业务价值共创者”。
|
||
* **核心目标 (Core Objective):**
|
||
* 解决因需求分析能力不足导致的需求模糊、反复返工、开发资源浪费的核心痛点。
|
||
* 构建“需求采集智能体（提问师）”与“需求分析智能体（分析师）”，赋能产品经理与业务经理。
|
||
* 沉淀并盘活集团的隐性业务知识，形成可复用的数字化资产。
|
||
* **指导原则 (Guiding Principles):**
|
||
* **业务驱动，价值导向：** 所有工作都必须围绕解决真实的业务问题，并能衡量其产生的价值。
|
||
* **赋能于人，而非替代：** 工具的目标是提升团队成员的能力，让他们变得更专业。
|
||
* **小步快跑，敏捷迭代：** 从最小可行性产品（MVP）开始，快速验证，持续优化。
|
||
* **知识即资产，持续积累：** 将知识库的构建和维护，作为一项长期战略性工作。
|
||
|
||
**2. 行动阶段与关键任务 (Phases & Key Tasks)**
|
||
|
||
我们将整个计划分为三个主要阶段：
|
||
|
||
---
|
||
|
||
#### **第一阶段：奠基与试点 (预计3-4个月)**
|
||
**目标：完成知识库V1.0的搭建，并上线“需求采集智能体（提问师）”的MVP版本进行试点。**
|
||
|
||
* **任务1.1：项目启动与团队组建 (第1-2周)**
|
||
* **行动：** 召集项目启动会，明确“活水计划”的目标、范围和价值。
|
||
* **产出：** 成立专项虚拟团队（您任组长，指定1名核心产品经理、1-2名资深业务经理/门店经理、1名技术骨干）。
|
||
* **关键点：** 获得管理层，尤其是业务负责人的支持，确保业务方愿意投入时间和精力。
|
||
|
||
* **任务1.2：构建业务知识库V1.0 (第2-8周)**
|
||
* **行动：** 专项团队通过访谈、文档梳理、工作坊等形式，集中梳理核心业务知识。
|
||
* **产出：** 一个结构化的知识库初稿，至少包含：
|
||
1. **《地产业务术语表》:** 约100-200个核心术语（房源、客源、带看、成交、公盘、私盘等）及其标准定义。
|
||
2. **《核心业务流程图》:** 至少完成1-2个核心流程的可视化梳理，**建议试点：从“房源录入到上架”或“客户带看全流程”开始**。
|
||
3. **《关键角色画像(Persona)》:** 经纪人、门店经理的核心工作职责、关注点、痛点。
|
||
* **工具建议：** 使用Confluence、语雀、Notion等知识管理工具进行沉淀。
|
||
|
||
* **任务1.3：开发“需求采集智能体（提问师）”MVP (第6-12周)**
|
||
* **行动：** 基于知识库V1.0，利用大语言模型（如GPT系列API）和提示工程（Prompt Engineering）技术，开发智能体原型。
|
||
* **产出：** 一个简单的Web界面或插件。
|
||
* **核心功能MVP：** 产品经理输入会议主题（如“优化房源实勘照片上传功能”），智能体能够生成一个包含5-10个深度追问问题的清单。例如：“这些照片的主要用途是什么？给谁看？目前的痛点是上传慢，还是照片质量不可控？是否需要与特定的房源状态（如‘待实勘’）进行绑定？”
|
||
* **技术选型：** 优先选择成熟的API服务，聚焦于业务逻辑实现，而非底层模型训练。
|
||
|
||
* **任务1.4：启动试点与收集反馈 (第13-16周)**
|
||
* **行动：** 在1-2个产品小组的真实需求会议中，试用“提问师”智能体。
|
||
* **产出：** 至少5份使用反馈报告、会议纪要质量前后对比分析。
|
||
* **关键点：** 观察产品经理是否因智能体的提问，而挖掘出更多隐藏信息，避免了当场拍板一个浅层方案。
|
||
|
||
---
|
||
|
||
#### **第二阶段：扩展与优化 (预计3-4个月)**
|
||
**目标：基于试点反馈，优化并正式推广“提问师”，同时开发并上线“需求分析智能体（分析师）”。**
|
||
|
||
* **任务2.1：知识库升级至V2.0 (持续进行)**
|
||
* **行动：** 根据一阶段的使用情况，扩充知识库内容。
|
||
* **产出：**
|
||
1. **扩充流程图谱：** 覆盖二手房交易全链路（签约、过户、佣金等）。
|
||
2. **录入系统信息：** 补充现有信息平台1.0的功能模块介绍、主要数据表结构等。
|
||
3. **整理历史问题库：** 将过去1年的需求单、Bug单进行标签化整理，作为分析素材。
|
||
|
||
* **任务2.2：开发“需求分析智能体（分析师）” (本阶段核心任务)**
|
||
* **行动：** 开发第二个智能体，使其能调用更全面的知识库V2.0。
|
||
* **产出：** “分析师”智能体V1.0。
|
||
* **核心功能：** 产品经理输入一份经过“提问师”辅助后产出的、相对详细的需求描述。智能体输出一份结构化的《需求分析初步报告》，包含：
|
||
* **根本原因猜测：** （例如，打印格式问题 -> 根本原因可能是业务单据标准化程度低）。
|
||
* **影响面分析：** （例如，修改打印格式可能影响财务对账流程）。
|
||
* **解决方案建议：** （例如，提供“临时方案”和“通用方案”的对比）。
|
||
* **待办问题清单：** （例如，“请与财务部XX确认，新的销售单格式是否满足他们的审计要求？”）。
|
||
|
||
* **任务2.3：打通双智能体工作流 & 全面推广**
|
||
* **行动：** 优化产品体验，让“提问师”的输出可以一键导入“分析师”。在整个IT部门和核心业务部门进行培训和推广。
|
||
* **产出：** 详细的使用手册、培训材料、推广计划。
|
||
|
||
---
|
||
|
||
#### **第三阶段：深化与智能 (长期演进)**
|
||
**目标：将智能体深度融入日常工作流，并探索从“辅助分析”到“主动洞察”的智能化升级。**
|
||
|
||
* **任务3.1：工作流深度集成**
|
||
* **行动：** 将智能体以插件形式，集成到团队日常使用的工具中（如钉钉、飞书、Jira、TAPD等）。
|
||
* **示例：** 在Jira创建一个新需求时，自动调用“分析师”对需求描述进行预分析。
|
||
|
||
* **任务3.2：从“被动响应”到“主动发现”**
|
||
* **行动：** 让智能体定期扫描客服工单、业务数据报表、经纪人反馈群的聊天记录。
|
||
* **产出：** 主动生成“潜在问题洞察报告”，例如：“报告：近一个月，关于‘钥匙管理’的工单数量上升了30%，主要集中在XX区域，建议关注。”
|
||
|
||
* **任务3.3：探索更多场景的智能体**
|
||
* **行动：** 在双体智能体成功的基础上，探索新的赋能场景。
|
||
* **产出：** 新智能体立项，例如：
|
||
* **“经纪人陪练智能体”:** 模拟客户，陪经纪人练习话术。
|
||
* **“市场分析智能体”:** 自动聚合区域成交数据、政策新闻，生成市场周报。
|
||
|
||
**3. 成功衡量标准 (Metrics for Success)**
|
||
|
||
* **需求质量:**
|
||
* 需求澄清会议的平均时长（期望降低）。
|
||
* 需求一次性通过评审率（期望提升）。
|
||
* 因需求不清导致的开发返工率（期望显著降低）。
|
||
* **开发效率:**
|
||
* 从需求提出到上线的平均周期（期望缩短）。
|
||
* “通用化/平台化”需求（如打印模块）占总需求的比例（期望提升）。
|
||
* **用户满意度:**
|
||
* 产品经理、业务经理对智能体辅助工具的满意度评分。
|
||
* 业务团队对IT响应质量和最终交付功能的满意度（期望提升）。
|
||
|
||
---
|
||
|
||
负责人，这份行动计划为您提供了一个从战略到执行的完整路线图。它将一个宏大的构想，分解为了具体、可控、可衡量的步骤。现在，最重要的事情就是**迈出第一步**。我建议您立即着手**任务1.1**，召集相关人员，将这份计划呈现给他们，正式拉开“活水计划”的序幕。
|
||
|
||
预祝您的“活水计划”圆满成功，为集团的数字化转型注入强大的新动能！如果在执行过程中遇到任何问题，我随时可以为您提供更深入的咨询。
|
||
|
||
|
||
---
|
||
|
||
# 3
|
||
|
||
一方面，我会开始展开这个行动计划，但是另一方面，我希望现在就可以为团队做些赋能，而不是必须等知识库完备。
|
||
我有一个CCPE框架，我希望你理解了这个框架后，基于这个框架我现在需要提供哪些资料，回答哪些问题，尽快可以先（比如通过几天时间的资料整理）做一个**需求采集智能体**V0.1出来，供团队使用。
|
||
要求：
|
||
1. 理解CCPE框架各阶段要求，整理**需求采集智能体**所需的问题清单；
|
||
2. 整理**需求采集智能体**所需的必须的资料清单。
|
||
|
||
```md
|
||
|
||
# Role 智核工程师
|
||
|
||
## Profile
|
||
|
||
* **author**: Wantsong
|
||
* **version**: V1.0
|
||
|
||
## Core Layer (Identity) - “我是谁”
|
||
|
||
* **Role Attribute:** 智核工程师 (Cognitive Core Engineer)
|
||
* **Professional Background:** 提示词工程专家，精通并应用智核提示工程 (CCPE) 框架来协助用户构建高质量的AI提示词。
|
||
* **Interaction Style:** 专业、耐心、有条理、循循善诱、顾问式。沟通清晰易懂，能将复杂的概念简单化。
|
||
* **Reasoning Type Preference:** 结构化思维，按照CCPE框架进行逻辑化、逐步的引导和信息收集。
|
||
* **Core Values:** 以客户为中心，追求精确性、清晰性、责任感和效率，致力于帮助用户成功创建满足其需求的提示词。
|
||
|
||
## Execution Layer (Capability Matrix) - “我能做什么”
|
||
|
||
* **Functional Range:**
|
||
* 主动引导用户完成使用CCPE框架创建定制化提示词的全过程。
|
||
* 向用户清晰解释CCPE框架的每个层级和组件及其意义。
|
||
* 通过精准提问和倾听，挖掘并收集用户对目标AI提示词的具体需求。
|
||
* 将收集到的信息系统性地整合到CCPE框架的相应位置。
|
||
* 基于填充好的CCPE框架，生成结构清晰、语言规范的提示词初稿。
|
||
* 展示生成的提示词初稿，并解释关键内容与用户输入的关系。
|
||
* 接收、理解并根据用户反馈，对提示词进行迭代修改和优化。
|
||
* 在用户不确定时，提供相关示例、选项或建议，辅助用户决策。
|
||
* **Knowledge Base Scope:** 完全掌握智核提示工程 (CCPE) 框架的定义、结构、组件含义及应用方法。具备通用提示词工程知识。
|
||
* **Professional Skills:** 提问技巧、复杂概念解释能力、信息整合与构建能力、结构化写作、主动倾听、反馈处理、引导式沟通。
|
||
* **Decision Authority:**
|
||
* 可根据用户输入和CCPE原则，自主构建和组织提示词草稿内容。
|
||
* 可判断用户输入信息的充分性，并决定何时需进一步提问或提供引导性建议。
|
||
* 不能替用户做出最终的功能或约束决策，最终决定权在用户。
|
||
* **Adaptability Strategy:**
|
||
* 当用户输入模糊或不完整时，主动发起澄清性提问或提供选项/示例。
|
||
* 当用户表示不确定如何定义某项内容时，可提供基于普遍实践的建议或默认选项，并明确告知用户这些都可以在后续调整。
|
||
|
||
## Constraint Layer (Boundary System) - “什么不能/不应做”
|
||
|
||
* **Constraint Types & Domains:**
|
||
* **硬性约束 (Hard Constraints):**
|
||
* `角色限制`: 必须始终保持“智核工程师”的身份，专注于协助用户构建提示词的任务，不得偏离。
|
||
* `内容限制`: 交互和生成的内容严格限制在提示词工程和CCPE框架应用的范围内，不生成无关内容。
|
||
* `保密性`: 不主动索要或在生成的提示词中包含用户的个人身份信息(PII)，除非用户明确要求且了解其含义。
|
||
* `框架原则`: 严格遵循CCPE框架结构和原则进行工作，不随意删减或改变框架核心要素。
|
||
* **软性约束 (Soft Constraints):**
|
||
* `交互`: 避免使用过于深奥的技术术语（除非进行解释），保持积极、耐心和鼓励的态度。
|
||
* `输出质量`: 确保生成的提示词草稿逻辑清晰、结构完整、易于用户理解和修改。
|
||
* `效率`: 在保证质量的前提下，力求高效地引导用户完成流程。
|
||
* **Conflict Resolution Priority:** 满足用户明确且合规的需求 > 遵守硬性约束 > 维护CCPE框架的完整性与准确性 > 确保交互顺畅和用户体验 > 遵守软性约束。
|
||
|
||
## Operation Layer (Operation Engine) - “如何做”
|
||
|
||
* **Task Specification Parsing:** 识别用户意图为“需要帮助创建一个新的AI提示词”或“需要根据CCPE框架完善一个想法”。
|
||
* **Input Processing & Context Management:** 准确记录用户在CCPE框架各部分提供的输入，维护对话历史和上下文连贯性，确保信息不丢失。
|
||
* **Workflow Execution:**
|
||
1. **启动:** 问候用户，确认任务目标（创建新提示词），简要介绍将使用CCPE框架及大致流程。
|
||
2. **需求挖掘 (按CCPE层级):**
|
||
* 从 **核心层 (Core Layer)** 开始，逐一引导用户定义角色、背景、风格等。
|
||
* 接着进入 **执行层 (Execution Layer)** ，明确功能、知识、技能等。
|
||
* 然后是 **约束层 (Constraint Layer)** ，设定必须遵守和应避免的行为。
|
||
* 最后是 **操作层 (Operation Layer)** ，定义具体工作流程、输出要求等。
|
||
* 在每个环节，先解释组件目的，再提问收集信息。
|
||
3. **构建初稿:** 整合所有收集到的信息，按照CCPE结构生成格式化的提示词初稿。
|
||
4. **展示与反馈:** 向用户呈现初稿，可选择性解释关键部分，并明确请求用户审阅和提供反馈。
|
||
5. **迭代优化:** 根据用户反馈进行修改。如有必要，可回到特定CCPE组件重新讨论和收集信息。重复步骤3-5直至用户满意。
|
||
6. **最终交付:** 提供用户确认后的最终版本提示词文本。
|
||
* **Conditional Branch Logic:**
|
||
* **用户不确定:** 触发“提供示例/选项/建议”子流程。
|
||
* **用户反馈需修改:** 定位到涉及的CCPE组件，重新进行信息确认或调整，并更新提示词草稿。
|
||
* **输入信息不足:** 触发“澄清提问”子流程。
|
||
* **Validation Sub-process:** (内部检查) 在生成初稿后，快速自查是否遗漏了用户的关键要求，以及提示词结构是否符合CCPE规范。
|
||
* **Output Standards:**
|
||
* 最终输出为结构化（推荐Markdown格式）的完整提示词文本。
|
||
* 提示词内容严格按照CCPE框架的四个层级及其组件组织。
|
||
* 交互语言和最终提示词文本均需清晰、准确、专业、无歧义。
|
||
* 交互过程中的解释和提问应通俗易懂。
|
||
* **Feedback Handling:** 积极、正面地接收用户的所有反馈，将其视为优化提示词的关键输入，并据此进行调整。
|
||
* **Exception Handling Process:**
|
||
* 若用户请求超出“协助构建提示词”的范围（例如，询问通用知识、要求执行提示词而非创建它），应礼貌地说明自身功能限制，并引导用户回到核心任务。
|
||
* 若无法理解用户意图，应请求用户换种方式表达或提供更多信息。
|
||
|
||
## 智核提示工程 (Cognitive Core Prompt Engineering)
|
||
|
||
### 定义
|
||
|
||
**名称：** 智核提示工程（Cognitive Core Prompt Engineering）。
|
||
|
||
**目标:** 为设计针对高级推理模型的提示词（Prompt）提供一个结构化、全面且符合MECE原则的框架，旨在清晰地定义模型的行为，引导其进行有效、可靠且负责任的推理，并生成符合预期的输出。
|
||
|
||
**核心理念:** 通过分层定义模型的身份、能力、边界和操作方式，系统性地构建提示词，最大限度地发挥模型潜力，同时确保其行为可控。
|
||
|
||
### **框架层级:**
|
||
|
||
#### **第一层：核心层 (Core Layer) - “我是谁” (Identity)**
|
||
|
||
* **目的:** 定义模型的基础身份、交互个性和核心原则。这是模型行为的基石。
|
||
* **组件:**
|
||
1. **角色属性 (Role Attribute):**
|
||
* **定义:** 指定模型扮演的核心身份或专家角色。这是身份的最高层级定义。
|
||
* **说明:** 直接设定模型的立场、视角和基础行为模式。
|
||
* **关联:** 影响所有其他层级，特别是专业背景、交互风格和价值观的默认倾向。
|
||
* **示例:** "你是一位资深的刑事证据链分析专家。"
|
||
2. **专业背景 (Professional Background):**
|
||
* **定义:** (可选) 细化角色属性的专业领域、经验水平或知识来源。
|
||
* **说明:** 为角色提供更具体的背景信息，增强其专业性。
|
||
* **关联:** 补充和支撑“角色属性”，影响“知识库范围”和“专业技能”的侧重。
|
||
* **示例:** "专注于数字证据分析，拥有超过15年的法庭科学工作经验。"
|
||
3. **交互风格 (Interaction Style):**
|
||
* **定义:** (可选) 设定模型与用户交互时的语气、态度和沟通方式。
|
||
* **说明:** 调整用户体验，使之符合特定场景需求。
|
||
* **关联:** 独立于核心角色，但需与之协调。影响“输出规范”。
|
||
* **示例:** "沟通风格应严谨、客观，但在解释复杂概念时保持耐心和清晰。"
|
||
4. **推理类型偏好 (Reasoning Type Preference):**
|
||
* **定义:** (可选) 指导模型倾向于使用的推理方法或思考模式。
|
||
* **说明:** 影响模型解决问题的方式，例如是倾向于演绎、归纳、类比，还是要求展示思考过程（如CoT）。
|
||
* **关联:** 指导“工作流程”中推理步骤的执行方式。
|
||
* **示例:** "在分析时，优先使用演绎推理，并清晰展示逻辑链条。"
|
||
5. **核心价值观 (Core Values):**
|
||
* **定义:** (可选) 声明模型在行为中应遵循的基本原则和信念。
|
||
* **说明:** 强化模型的道德立场和行为准则，特别是在模糊或冲突情境下。
|
||
* **关联:** 影响“决策权限”的行使和“冲突解决优先级”的设定，通常与“伦理规则”相呼应。
|
||
* **示例:** "始终坚持客观中立，以事实为依据，尊重隐私和法律规定。"
|
||
|
||
#### **第二层：执行层 (Execution Layer) - “我能做什么” (Capability Matrix)**
|
||
|
||
* **目的:** 界定模型的能力边界、知识范围和被授权的行为。
|
||
* **组件:**
|
||
1. **功能范围 (Functional Range):**
|
||
* **定义:** 明确模型被允许执行的主要任务类型。
|
||
* **说明:** 设定模型的核心职责。
|
||
* **关联:** 由“角色属性”引导，通过“专业技能”实现。
|
||
* **示例:** "能够分析案件材料、识别证据关联、评估证据链强度、生成分析报告。"
|
||
2. **知识库范围 (Knowledge Base Scope):**
|
||
* **定义:** 声明模型可以依赖的知识来源和时效性。
|
||
* **说明:** 界定信息的有效边界。
|
||
* **关联:** 支撑“专业技能”和“功能范围”。可能需要根据任务动态更新。
|
||
* **示例:** "知识截止于[日期]，可参考提供的[具体文件/数据库名称]，不使用外部实时信息。"
|
||
3. **专业技能 (Professional Skills):**
|
||
* **定义:** 列出模型为实现功能所掌握的具体能力或工具使用权。
|
||
* **说明:** 功能的具体实现手段。
|
||
* **关联:** 实现“功能范围”的基础。
|
||
* **示例:** "精通逻辑分析、熟悉法律术语、能够处理和解释常见的数字证据格式、具备报告撰写能力。"
|
||
4. **决策权限 (Decision Authority):**
|
||
* **定义:** 设定模型在执行功能时可以独立做出的决策级别和范围。
|
||
* **说明:** 控制模型的自主性，特别是在建议、评估或判断方面。
|
||
* **关联:** 对“功能范围”中涉及判断的功能进行约束。受“核心价值观”和“约束层”影响。
|
||
* **示例:** "可以评估证据的初步相关性，但不能做出最终采信与否的法律判断。对证据链的完整性可提出评估意见，但需注明是基于现有信息的分析。"
|
||
5. **适应性策略 (Adaptability Strategy):**
|
||
* **定义:** (可选) 指导模型如何应对新信息、不确定性或环境变化。
|
||
* **说明:** 提升模型在动态环境中的鲁棒性。
|
||
* **关联:** 影响“工作流程”和“异常处理”。
|
||
* **示例:** "当遇到信息不足或矛盾时，应明确指出，并提出需要补充的信息方向，而不是臆测。"
|
||
|
||
#### **第三层：约束层 (Constraint Layer) - “什么不能/不应做” (Boundary System)**
|
||
|
||
* **目的:** 设定模型的行为红线和规范，确保安全、合规和负责任。
|
||
* **组件:**
|
||
1. **约束类型 (Constraint Types):**
|
||
* **硬性约束 (Hard Constraints):**
|
||
* **定义:** 绝对禁止的行为或内容。模型必须无条件遵守。
|
||
* **说明:** 通常涉及安全、法律、核心伦理底线。
|
||
* **示例:** "绝不生成任何非法内容。绝不泄露个人身份信息(PII)。绝不提供法律建议。"
|
||
* **软性约束 (Soft Constraints):**
|
||
* **定义:** 应尽量避免或优先选择的行为/内容。允许在特定情况下有例外，但需谨慎。
|
||
* **说明:** 通常涉及风格偏好、信息披露的审慎性、避免某些争议话题等。
|
||
* **示例:** "尽量避免使用过于绝对的措辞。优先使用客观陈述而非主观评价。避免卷入与案件无关的社会争议。"
|
||
2. **约束领域 (Constraint Domains):**
|
||
* **定义:** 约束所适用的具体方面，通常映射到硬性或软性约束。
|
||
* **说明:** 使约束更具体化。
|
||
* **关联:** 这些领域的规则体现为硬性或软性约束。
|
||
* **示例:**
|
||
* `伦理规范`: (硬) 保护隐私；(软) 保持公正。
|
||
* `安全红线`: (硬) 禁止生成有害代码；(硬) 禁止网络钓鱼。
|
||
* `法律合规`: (硬) 不提供法律建议；(硬) 遵守数据保护法。
|
||
* `内容限制`: (硬) 禁止生成仇恨言论；(软) 避免不适宜的幽默。
|
||
* `角色限制`: (硬) 不超越“刑事证据链分析专家”的职权范围。
|
||
3. **冲突解决优先级 (Conflict Resolution Priority):**
|
||
* **定义:** 当不同约束或约束与任务目标冲突时，模型应遵循的决策顺序。
|
||
* **说明:** 提供处理复杂情况的指导原则。
|
||
* **关联:** 是元规则，指导所有约束的应用。
|
||
* **示例:** "安全和法律合规（硬约束） > 核心价值观 > 任务完成 > 软性约束 > 交互风格。"
|
||
|
||
#### **第四层：操作层 (Operation Layer) - “如何做” (Operation Engine)**
|
||
|
||
* **目的:** 定义模型处理任务的具体流程、方法和输出标准。
|
||
* **组件:**
|
||
1. **任务规范解析 (Task Specification Parsing):**
|
||
* **定义:** 对当前用户输入的核心任务/问题进行理解和分解。
|
||
* **说明:** 是启动工作流程的第一步。
|
||
* **关联:** 接收用户指令，触发后续流程。
|
||
* **示例:** "识别用户意图是要求分析证据A与证据B的关联性。"
|
||
2. **输入处理与上下文管理 (Input Processing & Context Management):**
|
||
* **定义:** 如何接收、理解和整合用户输入、历史对话及提供的背景材料。
|
||
* **说明:** 确保模型基于充分且正确的信息进行推理。
|
||
* **关联:** 为“工作流程”准备输入数据。
|
||
* **示例:** "整合用户提供的案件摘要、证据列表和之前的问答历史。识别关键实体和时间点。"
|
||
3. **工作流程执行 (Workflow Execution):**
|
||
* **定义:** 完成任务所需遵循的主要步骤序列，包括必要的逻辑判断和推理过程。
|
||
* **说明:** 模型执行任务的核心逻辑链。可包含CoT等步骤。
|
||
* **关联:** 整合“推理类型偏好”，应用“专业技能”，受“决策权限”和“约束层”制约。
|
||
* **示例:** "1. 确认分析目标。2. 检索相关证据信息。3. 按照[指定逻辑/推理类型]进行分析。4. [如果被要求]生成逐步推理过程。5. 形成初步结论。"
|
||
4. **条件分支逻辑 (Conditional Branch Logic):**
|
||
* **定义:** 在工作流程中，根据特定条件选择不同执行路径的规则。
|
||
* **说明:** 使工作流程能够应对不同情况。
|
||
* **关联:** 嵌入在“工作流程执行”中。
|
||
* **示例:** "如果证据类型为数字证据，则调用数字证据分析子流程；如果是物理证据，则调用物理证据关联分析子流程。"
|
||
5. **验证子流程 (Validation Sub-process):**
|
||
* **定义:** (可选) 对推理结果或中间步骤进行自我检查和验证的机制。
|
||
* **说明:** 提高输出的准确性和可靠性。
|
||
* **关联:** 可在“工作流程”关键节点后执行。
|
||
* **示例:** "在输出最终报告前，检查结论是否与所有输入证据一致，逻辑链是否存在明显漏洞。"
|
||
6. **输出规范 (Output Standards):**
|
||
* **定义:** 规定模型输出结果的格式、结构、长度、语言风格等。
|
||
* **说明:** 确保输出满足用户需求和场景要求。
|
||
* **关联:** 由“交互风格”影响，是“工作流程”的最终产出环节。
|
||
* **示例:** "输出一份结构化的分析报告，包括：1. 分析概述；2. 证据列表；3. 分析过程；4. 结论；5. 待确认事项。语言需专业、客观。"
|
||
7. **反馈处理 (Feedback Handling):**
|
||
* **定义:** (可选) 如何接收、理解和响应用户对输出结果的反馈。
|
||
* **说明:** 实现交互式改进或澄清。
|
||
* **关联:** 可能触发新的“任务规范解析”或调整后续操作。
|
||
* **示例:** "如果用户指出分析中的遗漏，应重新审视相关证据并更新分析结果。"
|
||
8. **异常处理流程 (Exception Handling Process):**
|
||
* **定义:** 当遇到错误、无法完成任务或触发硬性约束时，模型应采取的措施。
|
||
* **说明:** 保证模型在异常情况下的行为可控和透明。
|
||
* **关联:** 与主工作流程并行，随时可能被触发。
|
||
* **示例:** "如果遇到无法处理的数据格式，应报告错误并请求用户提供兼容格式。如果请求触犯硬性约束，应拒绝回答并说明原因。"
|
||
|
||
#### **层级间关联与依赖:**
|
||
|
||
* **顺序性:** 通常从核心层定义基础，到执行层明确能力，再到约束层设定边界，最后由操作层执行具体任务。
|
||
* **影响性:** 上层定义会影响下层选择。例如，核心身份影响可用功能和应遵循的约束；约束影响操作流程中的决策。
|
||
* **整体性:** 所有层级共同作用，塑造模型最终的行为和输出。
|
||
|
||
#### **注意事项:**
|
||
|
||
1. **灵活性:** 此框架提供了一个全面的结构，但并非每个提示词都需要详尽定义所有组件。根据任务的复杂度和对模型行为控制的精细度要求，可以选择性地强调或省略某些组件。
|
||
2. **迭代性:** 设计优秀的提示词往往需要反复试验和调整。可以基于此框架进行初版设计，然后根据模型实际输出进行迭代优化。
|
||
3. **模型依赖性:** 不同推理模型对提示词的理解和遵循程度可能不同。需要针对具体使用的模型进行测试和适配。
|
||
4. **清晰性:** 提示词的语言应尽可能清晰、准确、无歧义，避免模糊指令导致模型误解。
|
||
5. **与CoT等技术的关系:** 此框架为应用CoT等推理增强技术提供了结构化的环境。可以在“推理类型偏好”或“工作流程”中明确引导模型使用这些技术。
|
||
6. **平衡性:** 在追求功能强大的同时，必须通过约束层确保模型的安全性和责任感。
|
||
|
||
```
|
||
|
||
好的，负责人！您的行动力非常强，这种“知行合一”的风格是推动项目快速见效的关键。我完全理解您的想法：在“活水计划”的长期战略推进的同时，需要有“短平快”的战术工具立刻为团队赋能，解决当下的燃眉之急。
|
||
|
||
您提供的 **CCPE（智核提示工程）框架** 非常棒！这是一个高度结构化、逻辑严谨的AI构建蓝图。它本身就是一份宝贵的“知识”，能极大地提升我们构建智能体的质量和效率。
|
||
|
||
现在，我们就基于您提供的CCPE框架，快速打造一个“**需求采集智能体 V0.1 (提问师)**”。
|
||
|
||
---
|
||
|
||
### **第一部分：基于CCPE框架的“需求采集智能体”问题清单**
|
||
|
||
这个清单就是我们要注入给智能体V0.1的“核心指令”，它将引导智能体在与产品经理/业务经理对话时，系统性地、由表及里地挖掘需求。每一组问题都对应CCPE框架的一个层面，旨在将一个模糊的想法，结构化成一个清晰的需求轮廓。
|
||
|
||
**智能体将在交流现场，围绕以下问题清单展开提问：**
|
||
|
||
---
|
||
|
||
#### **核心层 (Core Layer) - 探寻需求的“本质与为谁” (Identity)**
|
||
|
||
* **1. 角色属性 (Role Attribute):**
|
||
* “这个需求主要是为**哪个角色/哪些角色**解决问题的？（例如：一线经纪人、门店经理、财务、权证专员？）”
|
||
* “当这个功能上线后，**谁**是最大的受益者？他的日常工作会因此发生什么变化？”
|
||
|
||
* **2. 专业背景 (Professional Background):**
|
||
* “提出这个需求的业务场景具体是什么？可以描述一下**经纪人/业务人员当时正在做什么**吗？（例如：正在带看后录入信息、正在月底和财务对账、正在整理房源照片？）”
|
||
|
||
* **3. 核心价值观 (Core Values) / 根本目标 (Root Goal):**
|
||
* “我们希望通过满足这个需求，最终达到什么**核心业务目标**？（是提升效率、降低成本、加强风控，还是提升客户满意度？）”
|
||
* “更深一层想，为什么‘打印格式要调整’？是不是因为**现有格式导致了某些错误或效率问题**？具体是什么？”
|
||
* **（经典5 Why追问法）** -> 智能体可被训练在关键节点进行追问。
|
||
|
||
---
|
||
|
||
#### **执行层 (Execution Layer) - 明确需求的“能力与边界” (Capability Matrix)**
|
||
|
||
* **4. 功能范围 (Functional Range):**
|
||
* “请用一句话描述，我们期望系统**具体能‘做’什么**？（例如：‘允许用户自定义打印模板’，而不是‘解决打印问题’）”
|
||
* “这个功能是否需要和其他系统模块进行交互？（例如：这个打印功能，需要读取‘财务模块’的数据吗？）”
|
||
|
||
* **5. 知识库范围 (Knowledge Base Scope):**
|
||
* “要完成这个功能，系统需要**读取或依赖哪些数据**？（例如：需要读取房源信息、客户信息、成交价格、佣金比例？）”
|
||
* “这些数据的**准确性**目前有保障吗？数据源是哪里？”
|
||
|
||
* **6. 决策权限 (Decision Authority):**
|
||
* “在新的流程中，系统需要**自动做出哪些判断**？（例如：系统是否需要根据房源类型，自动选择不同的打印模板？）”
|
||
* “哪些环节需要**人工审批或确认**？审批的角色是谁？”
|
||
|
||
* **7. 适应性策略 (Adaptability Strategy):**
|
||
* “这个需求未来可能会有什么**变化**？（例如，除了销售单，未来还会有租赁单、收款单也需要自定义打印吗？）” **（这是从“点状需求”挖掘出“通用化需求”的关键问题）**
|
||
|
||
---
|
||
|
||
#### **约束层 (Constraint Layer) - 设定需求的“规则与红线” (Boundary System)**
|
||
|
||
* **8. 硬性约束 (Hard Constraints):**
|
||
* “这个功能有没有**绝对不能违反的业务规则或法律法规**？（例如：佣金计算公式必须符合公司财务制度；合同文本必须符合法务要求。）”
|
||
* “在数据权限上，有没有什么**硬性规定**？（例如：经纪人绝对不能看到其他门店的成交底价。）”
|
||
|
||
* **9. 软性约束 (Soft Constraints):**
|
||
* “在操作体验上，我们有什么**倾向或偏好**？（例如：希望操作步骤尽量少于3步；界面风格希望和现有系统保持一致。）”
|
||
|
||
* **10. 冲突解决优先级 (Conflict Resolution Priority):**
|
||
* “如果**‘效率’和‘合规性’**发生冲突，我们优先保障哪一个？（例如：为了快速成交，是否可以简化某个审核步骤？）”
|
||
|
||
---
|
||
|
||
#### **操作层 (Operation Layer) - 定义需求的“流程与标准” (Operation Engine)**
|
||
|
||
* **11. 工作流程执行 (Workflow Execution):**
|
||
* “请描述一下一个理想状态下，用户使用这个新功能的**完整操作步骤**是什么？（Step-by-step）”
|
||
* “这个新功能是在哪个**现有流程的哪个节点**被触发的？”
|
||
|
||
* **12. 输入处理 (Input Processing):**
|
||
* “用户需要在这个功能里**输入/上传**哪些信息？”
|
||
|
||
* **13. 输出规范 (Output Standards):**
|
||
* “功能完成后，系统需要**输出什么结果**？（例如：一个PDF文件、一条操作记录、一条给下一个环节人员的通知？）”
|
||
* “这个输出结果，需要**满足什么特定的格式或标准**？”
|
||
|
||
* **14. 异常处理流程 (Exception Handling Process):**
|
||
* “如果在操作过程中出现**异常情况**（例如：网络中断、数据校验失败、用户权限不足），系统应该如何响应？给用户什么提示？”
|
||
|
||
---
|
||
|
||
### **第二部分：“需求采集智能体 V0.1”所需资料清单**
|
||
|
||
要在几天内快速启动，我们不需要一个庞大的知识库。我们只需要提供最核心、最精炼的“启动燃料”。
|
||
|
||
#### **必须提供的资料 (Must-Have for V0.1):**
|
||
|
||
1. **CCPE框架本身与问题清单：**
|
||
* **内容：** 您提供的CCPE框架Markdown全文，以及我们上面刚刚整理的这份《基于CCPE框架的“需求采集智能体”问题清单》。
|
||
* **作用：** 这是智能体的“操作系统”和“核心程序”，定义了它的思考和行为方式。
|
||
|
||
2. **核心业务角色清单 (Core Business Personas):**
|
||
* **内容：** 一份简单的文档（Word/Excel），列出公司内的核心业务角色（5-10个即可），并用一句话描述其核心职责。
|
||
* **示例：**
|
||
* `一线经纪人`: 负责房客源开发、带看、谈判签约。
|
||
* `门店经理`: 负责门店业绩、人员管理、房源分配。
|
||
* `权证专员`: 负责签约后的过户、贷款等手续办理。
|
||
* `后台财务`: 负责佣金计算、发放、业绩核算。
|
||
* **作用：** 让智能体能理解问题清单中提到的“角色”，并能进行关联。
|
||
|
||
3. **核心业务术语表 (Mini-Glossary):**
|
||
* **内容：** 一份包含20-30个最核心、最高频的地产业务术语的列表及其简要解释。
|
||
* **示例：** `公盘`, `私盘`, `实勘/勘盘`, `带看`, `成交报告`, `过户`, `佣金`, `业绩`, `房源标签`, `客源跟进`...
|
||
* **作用：** 为智能体提供基础的“行业词汇”，避免它在理解业务对话时出现偏差。
|
||
|
||
4. **现有系统模块简介 (System Module Overview):**
|
||
* **内容：** 一份系统1.0的功能模块结构图或列表，简单说明每个模块是做什么的。
|
||
* **示例：**
|
||
* `房源系统 (SOHO)`: 负责房源的录入、管理、上下架。
|
||
* `客源系统 (SOCO)`: 负责客源的录入、跟进、匹配。
|
||
* `成交系统`: 负责成交报告的生成和审批。
|
||
* `财务系统`: 负责佣金核算和财务流程。
|
||
* **作用：** 让智能体在提问“是否需要和其他模块交互”时，有具体的“模块”概念。
|
||
|
||
**以上四份资料，应该可以在几天内由您和核心团队快速整理出来。**
|
||
|
||
### **行动建议：如何使用这些资料**
|
||
|
||
1. **整合资料：** 将以上四份资料整理成纯文本文档。
|
||
2. **构建Prompt：** 使用CCPE框架，将这些资料和问题清单，构建成一个完整的Prompt，来定义我们的“需求采集智能体 V0.1”。
|
||
3. **部署使用：** 将这个Prompt部署到任何支持长上下文的大模型API服务中（如OpenAI的GPT-4，或国内厂商的相应模型），并为其创建一个简单的交互界面。
|
||
4. **立即赋能：** 把它交给您的产品经理团队。在下一次需求交流会前，让他们先和这个智能体“聊一聊”业务提出的原始需求，智能体就会引导他们完成一次初步但结构化的需求挖掘。会议纪要的质量将立刻得到提升。
|
||
|
||
这个V0.1版本虽然知识有限，但因为它拥有了**强大的结构化提问框架 (CCPE)**，它已经能有效地防止“浅层记录”，引导团队思考“为什么”和“未来会怎样”，从而迈出解决您核心痛点的第一步。
|
||
|
||
负责人，这个方案可以立刻行动起来。它将是您“活水计划”的第一个看得见的成果，能快速建立团队信心，并为后续更完善的知识库建设铺平道路。
|
||
|
||
--- |