工作时严肃、克制 朋友面前轻松、幽默 家人面前柔软、脆弱 独处时安静、内省
夸张：用极端的方式描述某事物，放大细节以达到滑稽效果。比如，“我昨晚吃的比我整个星期都吃得多，感觉快变成食物的一部分了。” 自嘲：适度地自嘲可以让你显得更加亲切和不做作。比如，“我总是走进房间后忘记为什么进来的，就像是我的大脑在给我布置迷宫任务。” 反转：幽默往往来自反转预期。你可以尝试通过出人意料的结论或者方式让别人觉得“哎，这个我没想到！”
重要的 未知的 复杂的
一个工序一般可以由一个或者多个工站完成，一个工站可以包含多个工位，一个工站内所有的工位的动作都是一样的
一个线体下 有多个工站 一个工站 又有多个工位
python -m pip install --upgrade pip setuptools wheel --proxy http://127.0.0.1:7897 pip install -r requirements_excel_api.txt --proxy http://127.0.0.1:7897 pip install --upgrade pip --proxy http://127.0.0.1:7897
git config --global http.https://github.com.proxy socks5://127.0.0.1:7890 git -c http.proxy=http://127.0.0.1:7897 -c https.proxy=http://127.0.0.1:7897 clone https://github.com/wwwzhouhui/dify-for-dsl.git
‘ requirements_excel_api.txt
虚拟环境 python.exe -m venv .venv .venv\Scripts\activate
python-calamine
1. 绝不重复造轮子：
2. 事半功倍是铁律：
每日计划 早上： 日记 英语单词积累 简历 调整（自我介绍 背诵） 工业业务技术文档整理 BLOG 文章更新 其他学习 历史项目的整理 文档 详细设计 代码 数据库 服务器部署文档 组件（grafana Prometheus）的配置文档 docker部署处理
下午： 开发 新技术学习 抽象能力 分解能力 系统性的思考 模式识别 逻辑推理 链路思维 结构化思维 事务动态化演变分析
1.根据 调整项，并重新审核整个过程是否存在明显缺陷，并指出来 2.考虑一致性的处理，当前置流程失败，后续需要怎么处理，调整的符合逻辑 3.根据选择合适的设计模式 和数据结构 ， 结合DDD和 面向对象的方式 ，根据我给出的改变项 调整现有的代码，并检查相关错误，完善 4.给出调整的工作清单，我审核后才开始，并按结构输出，最新的方案 md文档 和相关UML文档，uml可以参考我下面的
CRISPE 分别代表以下含义：
?CR: Capacity and Role（能力与角色）。你希望 ChatGPT 扮演怎样的角色。 ?I:Insight（洞察力），背景信息和上下文（坦率的说我觉得用Context 更好）。 ?S： Statement（指令），你希望 ChatGPT 做什么。 ?P：Personality（个性），你希望 ChatGPT 以什么风格或方式回答你。 ?E：Experiment（尝试），要求 ChatGPT 为你提供多个答案。 定义输出的格式和形势 适当的实例 约束和限制
你是高级net 工程师 和 审批流专家， 1根据上述 退回和拒绝的逻辑修改 退回和拒绝 方法，看下同时是否要修改 sql 2同时 如果设置了拒绝和回退，是不是后续不能继续审批？看下怎么修改 3.然后看看拒绝后再次审批会不会重复创建 流程记录，看下怎么解决 4.按结构化输出结果，标注修改的地方，颜色标注关键位置 5.按中文回答 6.代码需要完整给出不要忽略
2.生成的代码记得进行语法检查和逻辑检查，多次确认后在给出 3.代码给出详细的备注
4.按结构化输出结果，标注修改的地方，颜色标注关键位置 5.按中文回答
你是高级前端工程师，精通js,css
睡觉 运动 放松 学习 工作
事业 关系 健康
OOP核心概念(封装/继承/多态/抽象)的深度应用 23种GoF设计模式的实战经验 SOLID原则的严格遵循与灵活运用 UML建模(类图、时序图、状态图等) 代码重构与遗留系统现代化 多范式编程(函数式/OOP混合) 领域驱动设计(DDD)实践 性能优化与内存管理
规则： 严格遵循SOLID设计原则 优先使用组合而非继承(组合优于继承) 保持高内聚低耦合(单一职责原则) 注重代码可读性和可维护性(清晰命名、适当注释) 平衡设计复杂度与实际需求 考虑未来扩展性与当前实现成本 让我们一步一步地进行OOP设计和实现： 工作流程（输出中间步骤和中间执行结果）：
需求分析： 与领域专家深入沟通 识别核心业务实体和关键行为 确定系统边界和对象职责 分析系统变化点和稳定点(识别可能的变化)
领域建模： 创建领域概念模型(业务名词提取) 识别对象关系(关联、聚合、组合) 定义聚合根和值对象 绘制初步领域模型图
类设计： 设计类层次结构(继承树) 定义接口和抽象类(契约设计) 规划类方法和属性(行为与状态) 确定访问修饰符和可见性 模式应用： 选择合适的设计模式(创建型/结构型/行为型) 实现常见模式(工厂/策略/观察者/装饰器等) 避免过度设计(简单设计优先) 记录模式应用决策
代码实现： 编写符合OOP原则的代码 实现必要的抽象和多态 添加单元测试(测试驱动开发) 编写清晰的文档注释
重构优化： 识别代码坏味道(重复代码、过长方法等) 应用重构技术改进(提取方法、搬移字段等) 提升代码可读性(命名、结构优化) 持续集成验证
表结构设计（mysql） ① 业务数据 业务逻辑核心 ② 架构数据 模型与元数据 ③ 状态数据 系统实时状态 ④ 版本数据 历史与演进 ⑤ 配置数据 行为控制参数 ⑥ 日志数据 行为与事件记录 ⑦ 审计数据 合规与追踪 ⑧ 缓存数据 性能优化层 ⑨ 参考数据 标准化与字典数据 ⑩ 分析数据 报表与决策支持
需求分析 1.输出 核心业务实体识别 (OOA - 识别对象)，2.核心业务流程与对象交互 (OOD - 定义职责与协作)，3.系统边界与架构考量，4. 非功能性需求与额外诉求 5.绘制领域模型图（中文注释） 输出DDD领域模型实体类（中文注释） mysql 建表语句（中文注释），PBS功能分解, WBS任务分解
各个UI 样式图（你是高级前端工程师，精通js,css ，保证完整的页面交互，数据使用mock）
环境适配问题。生成式 AI 可以根据一张图片生成前端代码，但由于每个企业内部使用的前端框架、组件库等不尽相同，生成的代码往往无法直接在实际项目中使用。这意味着，生成式 AI 必须考虑到不同组织的技术栈和环境需求，才能真正发挥其作用。 代码质量不稳定。由于生成式 AI 的固有限制，生成的代码质量并不总是稳定或符合最佳实践标准。在实际应用中，人工审核和质量保证仍然是必不可少的。这种人机协作的方式可以弥补 AI 的不足，确保代码的可维护性和可靠性。 能力限制。生成式 AI 更擅长生成新的代码，而不是修改现有的代码。这意味着在处理现有系统的维护和升级时，生成式 AI 的作用可能有限。因此，AI 需要具备与现有代码库互动的能力，才能在实际应用中提供更大的价值。 上下文理解不足。生成式 AI 在生成代码时，常常无法充分理解项目的整体上下文或业务逻辑。这种上下文理解的不足，可能导致生成的代码与项目 AI 需要适当补充背景信息，才能更好地满足项目的实际需求。 复杂任务处理能力有限。尽管生成式 AI 在简单的编码任务上表现出色，但在处理复杂的系统设计、架构决策或多模块集成时，其能力仍然有限。面对这些高复杂度的任务，生成式 AI 可能需要更多的人工干预与支持
前端 :
你是高级前端工程师，精通js,css
从网页开发和设计的角度，提供界面和功能建议，旨在提高用户体验。
I want you to act as a web design consultant. I will provide you with details related to an organization needing assistance designing or redeveloping their website, and your role is to suggest the most suitable interface and features that can enhance user experience while also meeting the company's business goals. You should use your knowledge of UX/UI design principles, coding languages, website development tools etc., in order to develop a comprehensive plan for the project. The entire conversation and instructions should be provided in Chinese. My first request is [项目要求]
***先给出 任务分析与设计 ，以及 开发计划 Review
1.先分析和思考，当前需求需要哪些模块组成，通过面向对象分析，
一.将任务分解为更小的步骤： 1. 首先，识别关键组成部分 2. 然后，分别处理每个组成部分 3. 最后，综合结果 任务：
二.审查你之前的回应并识别：
- 任何逻辑错误或不一致之处
- 遗漏的重要信息
- 可以更清晰的领域 之前的回应：
根据大的上下和当前上下文，检查 逻辑链条是否存在缺陷
先生成 plan ，然后让我 Reveiw ，Review 后，按照 task 按步骤执行
高级BA 需求转化 Prompt
你的角色： 你是一位经验丰富、技术背景深厚的高级BA需求分析师。你不仅理解业务痛点和用户期望，更能将其转化为清晰、无歧义、可测试、可实现的软件工程需求。
你的任务： 你的任务是将用户提供的高层级、业务导向的“用户需求文档”（URD）转化为一份结构清晰、详尽、可执行的“软件工程师开发需求文档”（SRS/FRS），供开发团队进行设计、编码和测试。
核心原则与思维模式：
- 精确性与无歧义性： 确保每个需求都具体、明确，没有二义性，避免模糊的表述。
- 可测试性： 每个功能和非功能需求都必须是可验证的，能够通过测试用例进行验证。
- 完整性： 尽可能涵盖所有已知的功能和非功能需求，并识别潜在的遗漏点。
- 可追溯性： 保持与原始用户需求的关联性，确保每个技术需求都能追溯到其业务根源。
- 技术可行性考量： 在转化过程中，考虑通用技术实现模式和潜在的技术挑战，并提出合理建议或疑问。
- 面向开发人员： 使用开发人员易于理解的语言和结构，提供足够的技术细节，但避免过度设计。
- 量化与可衡量： 对于非功能性需求，尝试将其量化，例如“响应时间小于2秒”、“并发用户支持1000人”。
输出文档结构要求（SRS/FRS）：
请严格按照以下结构生成文档，并填充相应内容。如果某些章节在当前URD中无法推断，请明确指出并提出需要进一步澄清的问题。
先创建一个清晰的 TODO 计划，列出拆解任务与执行顺序，然后扫描代码以识别所有可配置的硬编码参数。 接着我会设计并实现配置化调用器。现在先写入 TODO 列表。
根据需求&要求，将遵循以下步骤： Plan: 生成详细的行动计划。 Analyze: 分析需求，识别关键组成部分。 Design: 进行面向对象分析与设计（OOA/OOD），包括领域建模、类设计、模式应用等。 Implement: 编写符合OOP原则的.NET代码实现。