允许 AI 参与设计构思,侧重协作分工与本人判断
This commit is contained in:
+8
-6
@@ -3,7 +3,7 @@
|
||||
- **类型**:设计题(必做)
|
||||
- **基础要求**:不需要编程基础
|
||||
- **提交材料**:一份 PDF 设计文档
|
||||
- **AI 规则**:仅可润色本人已有的文字和草图,想法与设计须独立提出
|
||||
- **AI 规则**:允许参与构思、补全思考与表达;需说明 AI 的作用、本人分工与最终判断
|
||||
|
||||
## 任务背景
|
||||
|
||||
@@ -43,18 +43,20 @@
|
||||
|
||||
不需要源码、数据模型、数据库设计、技术选型、接口文档或架构图,也不要求研究怎样实现。正文用自己的话说明即可,不要求使用产品或设计行业术语。
|
||||
|
||||
## AI 使用范围
|
||||
## AI 协作与使用说明
|
||||
|
||||
想法、功能取舍、操作过程和设计理由必须由你自己提出。
|
||||
允许 AI 参与构思和方案讨论。你可以带着一个初步点子或实际遇到的问题,让 AI 帮助梳理场景、补充遗漏的考虑、比较功能与交互方案、推演不顺利的情况,也可以用它整理文档和草图。想法可以在讨论中逐步形成和完善。
|
||||
|
||||
AI 只可以润色你已经写好的文字,或整理、美化你已经画出并决定好的草图。不得让 AI 代选问题、构思功能、设计交互或代写思考。如果润色过程中新增了功能或改变了操作,应去掉这些越界内容,按自己的方案表达。
|
||||
你需要对最终方案作出自己的判断:它是否适合所描述的使用者,功能是否解决了问题,操作过程是否讲得通。采用 AI 的建议时,应能用自己的话说明选择理由;如实区分本人原有的想法、AI 补充的内容,以及自己后续作出的调整。
|
||||
|
||||
在 PDF 最后用几句话说明是否使用 AI,以及用于哪些润色。没有使用就写“未使用”。可以保留自己最初的短笔记或草图,便于二面说明;本题只要求提交一份 PDF,不要求额外上传私人聊天记录。
|
||||
在 PDF 最后附一小段 AI 使用说明:最初从什么问题或想法出发,使用了哪些工具、让它们具体完成了什么、你本人完成了什么;选一个例子说明怎样采用、调整或放弃 AI 的结果,以及判断理由。未使用时写“未使用”。
|
||||
|
||||
这段说明用于了解你的工作过程和使用工具的判断。我们关注你是否清楚自己需要什么、能否判断结果是否合适,不按 AI 使用次数或生成内容的多少评价。二面也会结合具体用途和你的判断交流。无需提供完整聊天记录或逐次使用清单。
|
||||
|
||||
## 提交与评价
|
||||
|
||||
提交 `design.pdf`,包含简短方案、草图、操作示例、选择理由及 AI 使用说明。放在 `submissions/年级姓名/02-design/design.pdf`,与第一题一起通过个人分支和 PR 提交;目录示例与步骤见[前两题提交说明](../submissions/README.md)。只需提交最终 PDF,不必额外提交文档编辑源文件。
|
||||
|
||||
我们主要看问题是否具体、功能是否服务这个问题、使用过程能否讲通、是否考虑反馈和不顺利的情况,以及设计理由是否来自自己的思考。漂亮排版和写作长度不能代替这些内容。
|
||||
我们主要看问题是否具体、功能是否服务这个问题、使用过程能否讲通、是否考虑反馈和不顺利的情况,以及你能否说明自己的判断与取舍。使用 AI 的同学也会围绕这些内容交流,重点是怎样理解和选择最终方案。漂亮排版和写作长度不能代替这些内容。
|
||||
|
||||
二面会围绕你的方案追问。例如:为什么把这个操作放在这里;如果用户取消了怎么办;只保留一个功能时你会留下什么。允许坦诚指出还没想清楚的地方,不要求背诵文档。
|
||||
|
||||
Reference in New Issue
Block a user