边界 01
软件系统建设、改造与上线协作
包括业务系统、管理后台、小程序、APP、官网、题库引擎、报表看板与老系统改造等，重点在于把需求、权限、流程和数据链路做成可交付结构。
适配范围
当前更适合推进的，通常是这几类可交付、可协作、可验证的事项
我们更倾向于承接边界清楚、目标可验证、角色能协作推进的事情，而不是一开始就承诺所有结果。
边界 02
AI 提效、知识库接入与工作流试点
更适合先从客服、销售支持、文档引用、FAQ、内部流程辅助等真实场景切入，而不是一开始就追求全域自动化。
边界 03
产品共建、题库迭代与解释体系优化
适合把题库、报告、知识源、复测机制和产品入口逐步做成可持续迭代的结构，特别适合需要长期沉淀内容资产的团队。
边界 04
涉及持牌、审批或专业资质的事项需要提前单独判断
比如医疗诊断、治疗服务、法律意见、涉许可培训、就业保证、确定性经营结果承诺等，不适合在官网文案或首次沟通里直接承诺。
判断原则
比起先谈能不能做，我们更先判断这几件事有没有讲清楚
边界清楚后，项目才容易控制节奏、责任和风险。
原则 01
先看目标是不是软件交付、流程提效或内容共建问题
如果本质上是组织决策、牌照审批、法律结论或医疗判断问题，就不应被包装成一个普通的软件项目。
原则 02
不在官网和初期沟通中承诺确定性的经营结果
系统上线、流程改善和内容优化可以做；但收入提升、转化翻倍、匹配成功率等结果会受到运营、市场和执行条件共同影响。
原则 03
涉及敏感个人信息时，先收范围、权限和处理方式
尤其是心理状态、关系经历、职业测评、联系方式、聊天记录和内部资料等内容，需要在进入正式合作前就明确使用边界。
原则 04
非持牌事项不替代法务、医疗、心理治疗或培训资质
我们可以做系统、题库、解释结构和非治疗类支持产品，但不会把软件或内容包装成医疗诊疗、心理治疗、法律意见或受监管培训。
推进方式
如果按边界清楚的方式推进，通常会先经过这四步
先判断边界，再确定形式，比一开始直接谈所有功能更稳。
先说清楚目标、场景和当前阶段
先判断你遇到的是系统建设问题、AI 接入问题、内容产品问题，还是资质、审批、经营承诺一类不该直接软件化的问题。
再确认是否落在可交付边界内
如果属于软件、工作流、知识库、题库、解释报告或内容结构问题，就可以继续往下拆；如果涉及受监管事项，需要先单独判断。
明确资料范围、角色责任和首版目标
把谁参与、哪些资料会进入项目、哪些数据需要脱敏、首版验证什么结果先讲清楚，再进入排期和实施。
决定做正式项目、试点验证、顾问梳理或暂缓推进
并不是所有需求都要直接做完整项目，有些更适合先做试点、方案梳理或流程诊断，先把风险降下来。