应用内用户称呼需在AI确认方案前统一替换为业务专属词，否则代码生成后将固化“用户”导致多处错位；方法包括需求描述中直接定义、方案确认时强制指定全部替换维度、或通过结构化编辑框修改角色定义并校验冲突。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
统一应用内用户称呼的底层逻辑
码上飞生成的应用默认使用“用户”作为通用称谓，但实际交付场景中常需替换为“学员”“业主”“租客”“司机”等业务专属词——这类替换必须在开发流程早期完成，否则后期修改将导致字段名、提示语、权限描述、API返回文案全部错位。
关键前提是：【所有称呼替换必须在AI确认最终方案前完成】。一旦进入代码生成阶段，系统会自动将“用户”固化为数据库表名（如user_info）、接口路径（/api/user/list）和前端变量（userInfo），此时再改需手动逐文件搜索替换，极易遗漏。
方法一：在需求对话中直接定义
在首次输入需求时，把称呼写进原始描述里。例如：“做一个物业缴费小程序，服务对象是‘业主’，不是‘用户’”。
AI会自动识别并贯穿后续所有环节：PRD文档里写“业主信息管理”，后台菜单显示“业主列表”，登录页提示“请输入业主手机号”，连测试用例都写成“验证业主密码重置功能”。
这一步操作起来很简单，直接把业务角色词塞进第一句话就行。
方法二：在方案确认环节强制修正
当AI输出初步方案后，若发现它仍用“用户”，立即在对话框中明确指令：
“请将全部‘用户’替换为‘租客’，包括数据库字段、接口路径、页面标题、按钮文字、提示语、权限说明。”
注意：必须一次性列出所有需要替换的维度，否则AI可能只改前端文字而漏掉API路径。它不会主动追问你是否要改数据库表名，【不提=默认不改】。
方法三：用结构化指令覆盖默认逻辑
第一步：等待AI生成核心业务流程文档后，点击文档末尾的“分块内容评价”按钮；
第二步：在弹出的结构化编辑框中，找到“角色定义”区块；
第三步：将原内容“用户：系统访问者，无细分身份”改为“租客：已签约房屋租赁合同的自然人，拥有缴费、报修、投诉权限”；
第四步：提交修改，AI会重新校验全部关联模块并高亮标出3处潜在冲突点（如“租客”与现有“住户”字段语义重叠），你只需确认是否合并即可。
