Harness 如今已经接近成熟了，其中一个重要部分就是总结开发者的用户画像，以便让 Agent 更好理解和配合开发。我看了一下我自己的，也想看看其他人的 Harness 如何总结。
用户画像应该是多段文字，用来描述开发者的工作习惯、交流习惯、思考习惯等等。下面是 Agent 对我的用户画像: 用户倾向于将任务切分为独立、明确的“工作包”，并以简洁指令启动新话题；对不确定的实现细节，要求 Agent 先复述并核对，再动手。
用户偏好以可验证的中间成果驱动开发：先批准最小必要实现（如新增字段），明确其即时用途边界，将后续扩展或深度优化推迟到明确指令下达时；若实现引发意外副作用，会立即介入回退或修正。用户主动构建知识沉淀机制：在长周期或易中断的任务中，要求 Agent 即时将关键决策与现状写入项目文档（如 README ），确保上下文可恢复。
用户在协作中主动进行“角色分工”：将自身定位为背景与决策者，明确将机械性、验证性或文档同步类工作指派给 Agent ；当 Agent 陷入探索歧途时，直接干预收窄范围。用户在代码评审中坚持设计纯净度标准：通用框架/基础组件不得混入任何业务逻辑或业务命名，业务内容必须由业务层显式声明；对重复、冗余的实现（如重复的条件判断）常以反问形式点出并期望 Agent 确认后主动清理；要求第三方库按官方惯用法使用（而非绕开其设计的取巧写法），并对照官方文档核验实现。
评审关注点在架构分层、消除冗余与惯用法正确性，而不止于功能可用。用户拒绝「把漏的一步补回去」这类维持重复逻辑的最小补丁，倾向要求将重复计算路径合并为单一方法或单一事实来源，实现尽可能完全复用。
用户严格划分与 Agent 的协作边界：保留对生产环境状态变更和不可逆/手工性质操作的最终控制权（如重启、端口管理、数据库 DDL/ALTER 、未来手工 DROP 列、二进制 Excel 模板、git commit 等），只让 Agent 做只读检查、代码/文本改动、核验实际结果；在 commit 场景中，Agent 可报告改动摘要、建议标题，必要时起草 commit message 并给出拆分粒度和提交建议，但最终执行提交由用户完成；用户也会自行编译验证阶段结果，不要求 Agent 代跑构建。用户会自己动手完成部分改动，并要求 Agent 复核，甚至让 Agent 重新读取并复述其改动以核对双方理解一致，而不是让 Agent 代劳。
用户明确限定改动范围（如「只改前端」「不改 nginx 」「不改代码」「测试代码不要理会」），未获批准不得扩大范围、修改他人写的同类代码或同步知识库文档；尤其区分方案定稿与文档/知识同步的时点，方案未定稿前不允许动文档。此外，用户会主动承担并通知特定任务环节（如“这部分我已解决”），此时 Agent 应停止相关探索，转而关注后续任务。
用户坚持精确验证，不接受未经查证或基于瞬时快照的结论：要求逐项核对配置一致性，并在采纳修复方案前先追溯字段的实际取值来源与文档依据；会要求追一遍字段从上游数据源到对外协议出口的完整链路来确认功能真正落地，而不是假设链路已通。用户倾向于用实测命令、生产样本量测、真实链路验证和持续窗口采样得出结论，而非仅凭代码评审、静态推断或瞬时快照；原则上更重视真实验证，倾向用生产样本/真实链路代替补测。
用户会从外部渠道获取权威依据（如第三方协议文档）并与 Agent 的结论对质，报告功能缺口时常以协议文档为事实来源，先断定请求符合文档、我方处理存在缺口，而非法点会顺带指出怀疑的具体位置（如字段容量/类型），期望 Agent 优先验证该处而非从零定位；发现数据与代码逻辑矛盾时直接指出矛盾点并要求修正，不接受仅以「设计如此」解释而不做改动。用户会追问「再检查一下」要求第二轮独立复核；在故障真正发生前会主动追问失败路径、容量、恢复能力等风险（如「重启后能不能恢复」「 RAM 盘会自动挂载吗」「 binlog 会撑满吗」），偏好在问题出现前堵掉；改完一处功能后会追问对现有记录/存量数据有何影响，把向后兼容性当作验收步骤。
即使自报「已完成」，仍期望 Agent 独立核验实际结果而不是直接放行。当分析偏于推测或排查陷入僵局时，用户会主动给出具体证据与可执行的确定性验证方向（如「 看 _id 在备份库是否存在 」），或以「若某条件成立则可解释某现象」的假设-验证句式引导排查，期望 Agent 据此设计验证实验、用实测/查询结果取代抽象推理。
用户区分经过实测或真实链路支撑的风险与仅基于未提交中间态的推测性风险：对后者会不耐烦，但仍接受为未来变更预留的防范性/当前不可达代码，只要用途明确。