程序員如何看待美術工作人員？

12-30

大概是這麼回事，我是一名遊戲特效師，大概4年多的工作經驗，一直都使用的是unity 3d 。現在找到一家公司，開的新項目。這邊的程序員則是剛開始摸u3d，今天才正式弄項目規範，我早上上傳了一些東西，但因為沒有規範嘛，我的工作內容命名就很隨便的寫了，項目也沒有真是投入製作(人還沒召齊)，下午主程就劈頭蓋臉給我一頓說(反正平時看他就天天黑臉)。最重要的是都是雞毛蒜皮的小事情，比如一定要傳配置文件啊，文件命名不能有中文會報錯之類的，項目文件多誰都難免有出錯的時候，我不信哪個程序員跟我說他寫的代碼肯定沒bug。的確，我是有錯在先，但我覺得工作中起碼大家是平等的，沒有必要上來就劈頭蓋臉說吧，好好溝通，人與人之間的尊重總要吧。現在讓我覺得他是剛上手u3d，都沒摸索完，就必須按照他的思路來制定規則，否則肯定出問題。我從業4年多，別的不好說，關於u3d的特效模塊，我覺得能出的問題我都能解決，如果一直這樣的態度，讓我會覺得後續的工作我無法跟他溝通，交接(可能是我矯情吧，但一直這樣我真忍不了)在最後，我想問問各位程序大爺，是不是覺得美術都低程序一等！好了，我發泄完了。。

前面也許是我沒說清楚，我是在自己工程文件中有中文命名，是自己試效果那種，你們也可以說我習慣不好，但上傳後的命名因為是還沒制定標準，但都是英文且沒有空格的。他跑過來就說我和場景組長的東西各種亂(因為就我倆上傳了東西)，也不說明白哪裡亂就走了。我也不再解釋了，感謝各位的回答，讓我認識到自己的不足，也許我以前碰到的程序都太好說話了，這次算個挑戰吧！

看了題目描述感覺一陣心虛，還以為在說我…

後來又仔細看了一遍，應該不是…

但是作為主程，我曾經跨部門黑臉跟新入職的特效師「探討」過一次文件命名問題。並引起了美術老大的不滿，不過我馬上採取行動，緩和了矛盾。不同的是那個小夥子是個新人，而不是工作4年的老兵。

那也是項目剛開始，團隊剛組建，第一個Unity項目，所有規範都在編寫中，不同角色之間的配合方式也在摸索。文件命名也只是跟美術口頭說了一下，只能用小寫英文字母數字下劃線，具體文檔還在寫。有一天我update了一下，突然發現了一堆中文，大寫，空格亂七八糟的文件，還給我刪了幾個文件。當時的感覺就像吃了老鼠屎一樣。找到那個提交的美術給他又講了一遍文件命名規範，當然，全程黑臉，而且聲音比較大，我是故意的，就是想讓美術們都重視一下文件命名。我覺得是對項目好，但事實上會給美術領導「在我地盤上撒野」的感覺。他們頭跑過來說，這位特效師是個新人，svn剛學會，別這麼說他。我馬上就意識到了這麼做不妥，稍微安慰了一下小夥子，馬上回去把所有規範補充完整發了出來。

回過頭來討論一樓主的事，我覺得樓主更不滿的是這位程序員的態度，而不是這件事的本身。

樓上有位兄弟說了，Unity支持中文路徑，所以美術命名中文沒問題。我並不同意。

我們的所有規範，包括項目文件的命名規範，程序的編碼規範，都是要限制本來的自由度，達到控制風險，利於協作的目的。而不是引擎，編譯器支持到哪，我們就規範到哪。要求再高一點，就是項目中的所有文件都整齊劃一，看著也舒服。表現的這個團隊有組織有紀律。不是更好嗎？

至於這位程序員的態度，那就因人而異了，就像我，平時並不怎麼愛發火，但那次也露出了黑臉，所以，態度問題不好評論，需要樓主自己去分析了。

最後，說一下「怎麼看美術」。我遇到的美術，大多比較崇尚自由，內心不太喜歡規範、制度、管理工具這些東西。而且大多英語不好，英文命名有困難。所以作為管理人員，需要更多的耐心去說服，講解，完善規範，貫徹實施。

以樓主所從事的特效師為例，很多人其實是從網上找來現成的資源，稍作修改，或者不改就用了。所以容易形成不好的習慣，我想這也是樓主作為4年老兵依然不重視命名規範的原因。而且如果是自己做實驗，一般都是自己搞一個工程，做完了在提交到項目工程中去。

後來，我定的規則是，策劃提美術需求的時候，會提一個資源名作為前綴，寫到文檔裡面。美術做為命名基礎。

以上，希望對樓主有幫助。

我是程序出身，對美術也略懂，從原畫到3D模型到動作到特效都涉獵過。

根據問題描述，很遺憾，的確是你有錯在先。

團隊協作中，每個人都得對提交上去的內容負責。

你有4年的經驗，Unity 資源中不能用中文命名，不能帶空格這是很基本的原則，你犯這樣的低級錯誤自然會被同事認為不專業。

同樣道理，如果一個程序員提交的代碼，先不管有沒有 bug，要是一運行就報低級錯誤，這個程序員絕對會被其它程序員嫌棄，也會被上司罵得狗血淋頭。

這件事情，你直接道個歉，說以後會更加註意就解決了。現在憋了一肚子氣跑來知乎提問，說明你的職場情商還有待提高。而且這個程序員說了他願意制定資源規則，你就按照他的意思照辦唄。這時你有兩條選擇：1.大度一點，將自己的經驗也分享出來，一起做好這個項目。2.腹黑一點，等他制定的規則弄砸了再出來批判。現在項目還沒開始，你就臆斷將來肯定會有溝通障礙了，就假定程序員的 Unity 水平低於你了，這很不利於團隊協作。

程序員並非都是大爺，但普遍而言，程序員在項目中的重要性的確要高於其它職位，從市場平均薪資水平就能體現出來，程序員的工資起碼是其它平級職位的1.5-3倍。有的程序員很好相處，有的愛鑽牛角尖，有的脾氣怪異，因人而異。怎麼跟他們打交道，只能在工作中慢慢磨合。

另外必須說一句，如果是項目是從零開始搭建（非換皮項目）， Unity程序員的工作比特效工作難度是要高許多的。題主如果不服氣，可以業餘自己學一學程序，學得越深，你會越站在程序員那一邊的。

最後說說程序員如何看待美術人員。

我特別佩服有創意有思想的美術人員，他們能創作出美輪美奐的作品，畢竟一款遊戲最重要的是給玩家的第一印象。但就我接觸過的美術人員來說，真正天賦異稟的大師級的不多，他們往往是脫離一線工作的主美了。真實世界裡更多的美術人員做的事情其實是加工，而不是創作。像流水線工人一樣，拿到美術需求後，按照市場上某個風格仿製一份出來。既然是流水線工作，我個人更喜歡認真專業的美術人員：

按照規範，提供的美術資源能清晰命名，正確分目錄放置。
認真對待美術源文件，PS或 AI 的圖層合理劃分。方便以後修改。
定期整理自己的素材庫。電腦里的文件夾安排合理。
製作美術素材時，多做30%。譬如製作10個道具圖標，成熟的美術人員會多做幾個以便隨時替換。而不是做夠數就算了。
面對不合理需求時能有自己的想法，據理力爭。
對項目有前瞻能力，能分批分階段地提供素材，避免到項目後期美術全推到重做。這裡有領導傻逼的原因，也有美術人員本身沒有溝通好的責任。

看了一下回答，對於中文文件名的問題，雖然 Unity5 以後對中文支持好了很多，但美術素材還是建議強制性英文命名且不能帶空格。因為這些素材可能會通過 Resource.Load 來讀取。這些文件名很可能要被批量存放到 csv 文件里， csv 文件很可能某個時候被其它人用 Excel編輯（在 Windows，Mac，甚至在網頁上編輯），一不留神中文就全成亂碼了。所以，為了避免潛在的隱患，強制規範比較好。

對於多做30%，回答里反對聲特別多，我能理解。美術其實是個挺苦逼的工種。在遊戲開發團隊里，策劃一般口才較好，與人爭辯有優勢；程序可以裝高深，把外行唬住；唯獨美術，任何人都可以對其指手畫腳，每個人都認為自己有品位，一句「不好看」，「感覺不搭」，「還不夠酷炫」，就能直接推翻美術辛辛苦苦的成果，全都要重新做。而且美術出活都是實實在在肉眼能看得見的，忽悠不來。

在此我只能說，這是做自己的遊戲跟在公司打工的區別。我們團隊里，多做2-30%是常態。策劃在設計關卡、道具時要多想一些。美術在找素材，製作的時候也得多做一點。畢竟項目進度趕，修改階段做減法要比做加法更容易。美術在原設階段，肯定會多出幾個設計稿的。3D建模階段，是否多做幾個模型這個不好說，但是多畫一兩張貼圖，讓怪物可以增加種類這個很常見吧？

大家抵觸多幹活，無非是擔心多做的是無用功。而且害怕多做了，上面還覺得你精力有餘，下回給你更重的任務，如此惡性循環。其實在工作中，自己多做一點，積累的還是自己的經驗。多做的部分可以自己藏著，不報上去，等上頭的修改意見來了，自己應付起來也遊刃有餘，何樂而不為？

在程序上多做30%，不一定指多寫30%代碼量。程序員在寫完功能後，能主動多花時間去優化、重構代碼，讓代碼量變得更少更優美，這也照樣是難能可貴的事情。當然，這一切必須是在功能完成的基礎上。有的程序員拿重構來作為拖延進度的借口，「不重構就寫不下去」，「別人的代碼太爛實在沒法接著開發」，等等..... 這類行為是很 low 的，不過也特別常見，總之一言難盡。

4年經驗還犯這種低級錯誤？也許就這一個小錯誤，你覺得沒什麼大不了的，別人可能就因為這個加班一夜才找到原因

我覺得你們公司可以考慮招一個TA了。

題主別太委屈，畢竟你自己也是有不足，好好乾，祝你早日跳槽。

脾氣和本事一般都是成反比的。

你們主程有這個時間發脾氣，早就可以去寫一套asset manager和各種DCC Tool的導出工具了。這樣在導出的時候他就可以自然而然的規範命名了。同時在WIKI上分享你們的命名規範，沒事做兩個workshop，美術也不是沒事找事非要用自己的方法命名的。

這個就跟不讓我隨地扔垃圾但是又不給我垃圾桶一樣概念。

舉個例子：PS下面的圖層劃分，我們就是工具自動生成，結構一目了然，便於管理，這樣美術只要在相應的圖層下面創建layer即可。

關於Unity中文英文的問題，Unity是支持中文的，只是會有很多坑要踩，不是很建議

最後！

我看到一個大兄弟說了這樣的話：Unity程序員的工作比特效工作難度是要高許多的。題主如果不服氣，可以業餘自己學一學程序，學得越深，你會越站在程序員那一邊的。

隔行如隔山，特效工作的難度絕不是您這種，程序出身，對美術也略懂，從原畫到3D模型到動作到特效都涉獵過, 可以評價的。越是半瓶子水的人越晃蕩，越是學的深的人越會對自己未知的領域產生恐懼。我承認程序員的工資是比美術人員總體上要高，但這並不應該是你們優越感的來源。

我和微軟的程序員做過遊戲，和google的程序員做過遊戲，和2k的程序員做過遊戲，和nvidia的程序員做過遊戲。他們都很謙虛，他們也會承認shader好難寫，他們也會說gameplay簡單，但是對特效一竅不通。

術業有專攻，請對你們不了解的行業充滿敬畏，這是我認為的程序員應該怎麼看待美術人員。

先說一下觀點：制定完善的標準就為了不給其他人添麻煩。

國內遊戲美術崗位分工一般是這樣的：

負責美感和創意的概念設計，美術宣傳。負責製作部分的2D素材，2D特效，2D骨骼動作，3D模型，3D綁定，3D動作，3D特效，地編。還有工作內容比較雜的UI。有的團隊還會配技術美術，比如端游和主機遊戲。

概念設計這個工作除了需要做美術上的美感和創意探索，還需要對遊戲引擎有一定的認識。因為遊戲開發前期階段需要考慮到遊戲引擎的特性，還有遊戲平台的特點（比如PC客戶端，PC頁游，手游，主機，掌機等等）。需要考慮引擎內視角和同屏人數來決定角色外形複雜程度，層級有多少，動作和特效複雜程度等等。還需要根據引擎特性來考慮材質還有畫面整體風格。這個階段之後就會出一系列概念圖，配合流水線下游美工出DEMO，和技術美術還有程序來對引擎內各種效果進行試驗探索，並逐漸制定下一步美術製作標準。

*關於引擎與畫面風格詳見：

對遊戲來說，如何歸納和分類美術風格比較合理？ - 來須蒼真的回答

在遊戲原畫中，最「不重要」的就是色感和光影感，對嗎？ - 來須蒼真的回答

然後流水線下游美術團隊開始按照上一步制定好的標準進行製作，這個時候一般公司都會由各個部門的組長對組員提交的素材進行標準和質量上的審核，如果不夠細心有命名出錯或者格式問題，這個環節一般都會被打回去修正。這麼做是為了提升效率，避免給其他環節的工作添麻煩。(難道這不是天經地義的嗎？）

因為標準化的完善，所以流水線中下游的工作是可以完全外包的，只需要留少量的概念設計師或者主美對外包資源進行審核並提出反饋。

UI一般只需要畫icon logo和設計各種邊框，只有需要實現特殊交互效果的時候才會去配合特效還有程序員，一般情況下在引擎里拼UI都是執行策劃或者程序員的活。

美術宣傳可以完全外包，全程不參與和程序的對接。

--------------------

可能是因為題主所在的公司不大，並沒有在項目中形成標準，所以才會出現你直接跟程序進行交接，並且出錯。不過我很不能理解的是，一個從業4年的特效，這些標準難道不是業內公認的嗎？居然還需要特地去提醒？

-----------------

講一講我當年還在做3D美術時候的故事。

當年所在的是一家日本外包公司，所接的項目都非常雜，有影視高模，也有3DS遊戲的超低模。

每次接到新項目公司都會組織培訓，對項目標準進行說明，比如命名，格式，分組方式，只可以用哪些軟體，甚至有些要求變態到場景文件必須達到某一數值的大小，比如6MB，多1kb少1kb都不行，有的項目還需要用他們日本總公司下發的插件來檢查文件，文件提交前往往需要花半天時間去整理。提交的時候組長和項目經理都需要過目檢查，如果有沒檢查到的錯誤直接交到總公司，出反饋的時候是需要扣績效的，簡直沒人性。

日本人辦事一板一眼非常繁瑣，我當年作為一個新人是非常不理解的。直到我後來去國內自研發公司參與了一系列亂七八糟的項目之後才明白日本人的用心良苦，制定完善的標準就為了不給其他人添麻煩，這樣就省去了很多重複返工，推倒重做的無用功，也不用耗費多餘的精力去和跟你對接其他環節的人撕逼，大家都開開心心，少加班。

請對你工作中的其他類型職位同事抱有尊重，大家賺錢都不容易。

非程序，苦逼小策劃一枚。但是策劃你們懂的，程序，美術，運營，策劃，測試都要交流溝通。

首先呢，我對題主非常不爽的一點在這段：

最重要的是都是雞毛蒜皮的小事情，比如一定要傳配置文件啊，文件命名不能有中文會報錯之類的

什麼叫雞毛蒜皮的小事情！你知不知道！策劃跟程序有時候找了大半天的BUG，就是為了找你這所謂的雞毛蒜皮的小事情！這些東西就是因為它小！所以相對來說有時候不好發現！對，修改起來很快！改個名字，上傳下配置文件，幾秒鐘的事情。可是，題主考慮過其他人的工作時間么？其他人（測試、程序、策劃都會跑遊戲）發現了BUG以後，馬上通知相關的配置人員。然後程序、策劃就在那裡看自己是不是配錯東西或者代碼寫錯。

有時候可能一下子就找出來問題，但是也有可能找了幾十分鐘才找到問題所在。我們折中下，按每次找都需要花費10分鐘時間（不長吧）。就因為這種低級的錯誤，你佔用了其他人的時間。最重要的是，在項目開發中，並不是只有哪個部門人員需要進行設計思考！程序、美術、策劃都需要進行設計思考。（測試好像需要的是邏輯這方面思考，具體不是很熟悉，如果有錯歡迎指出）。

你畫圖畫到一半的時候，作為策劃的我，強制打斷你的進度，讓你花10分鐘時間畫個小圖標。請問你的感受如何？

合作過的程序、美術都不少。

美術一般都會有點藝術家的氣質，程序猿一般都思維比較嚴謹或者說無趣。但一般大家好好說話就沒什麼問題了。

不管是跳槽以後接別人的鍋或者是自己參與開發設計的坑，我一般都會看目前的項目有沒有對應的規範，如果沒明確的規範，就問下有沒有什麼需要注意的東西。如果不小心犯了錯的話，先道個歉，然後改一下，自己盡量注意不再犯。

時不時地跟其他人打下交道，例如派點零食什麼的（當然，主要是因為我自己也愛吃零食），跟其他人的關係打好點。大家工作的氛圍會好很多。不說都是為了讓公司有家的氛圍這種虛偽的話。主要是盡量讓自己工作的地方，變得自己去上班的時候沒那麼反感。

一起加油吧！

廣義的來說：宮崎駿也是個美工（算原畫？）

比爾蓋子也是程序

美工和美工是不同的，程序和程序也是不同的

不要隨便貼標籤

對你：有則改之，無則加勉。

對程序：溝通最重要的是要有成果。

成熟的團隊第一思考是發現問題，解決問題。

其實這個事情裡面誰都不能算有錯，只是合作出問題了。每個人有每個人的習慣和性格，這是一個項目對於製作人來說最需要技巧的地方之一——如何捏合他們合作。

這個問題從軟體工程的角度來看，是項目開始的時候一些定義工作並沒有做好導致的，所以很簡單的就是回到這個階段，我們重新定一下一些內容，包括名詞、規範等。

而現在還帶來了另一個問題——主程如何與人相處，從題主的描述來看，題主屬於比較弱勢的人，還能勉強被「欺負」，但這並不代表所有人可以忍受。如何培養好這個主程的第一個問題就是如何讓他變得更容易與人相處。

見到能正確命名資源的美術，水平都不會差。命名亂七八糟的，水平基本也就那樣了。當看到美術上傳的資源名字是 1111111，xxx123，aaaa，——————ab_ 之類的時候，你知道我有多崩潰嗎。

「各負其職」-中國遊戲公司的弱點。

往往越在製作流程的上遊人員，對遊戲的最終結果了解越少。因此一些規範要求理解或執行起來越馬虎。造成這樣的原因就是因為，超出了自己的工作範圍的知識，認為是多餘的知識，覺得做好本職以內的事情就好了。往往一點馬虎會讓下遊程序來承擔惡果。

遊戲系統不是一個橡膠、金屬、電路板、幾種不相干材料組成的機器，而是一個生命，每個細胞里都有相同DNA的生命。因此在各個部門工作開始的時候，它們應該具有一致的核心架構理念，充分統一，了解全局的知識。

題主遇到的問題，其實就像來自幾個不同身體的零件拼湊在了一起，沒有共同的意識，導致的結果。也表現出大多遊戲公司上游（大都是美術工種）感覺低程序一等的原因。因為一旦系統出錯，一句：「我不會啊，我不懂啊，不早說啊，只是稍微馬虎了一下而已。」就可以掩飾自己，對工作職能以外知識匱乏的現實。有些程序必需了解美術知識，但美術往往放棄了學習程序知識。

學習分文科理科，工作分美術程序，職位分份內份外，知識分有用無用，專業分內行外行。生生的把一個遊戲團隊割裂成了兩個敵對的團體。

遊戲人只分更精通什麼，每個人更應該走一遍全部的流程。

說句傷題主的一句話：你不是特效師，只是流水線上的特效工人，沒有按標準出活而被下游的程序工人指責了而已。既然在行業中工作了4年，為什麼新團隊不是你這個老人來制定流程？不僅如此，還犯「中文名，空格，數字開頭，計算符號」來命名文件的低級錯誤？

美工們，如果有一天你告訴程序應該怎麼寫才能完成美術效果後，你們才算真正的業內人士了。

知識沒有邊界，你是一個行業邊緣的美工，還是一個遊戲行業核心裡的製作人，自己來決定。

首先，bug是bug，規範是規範，二者沒有可比性，出現bug是正常的，但是沒有規範或者不符合規範，肯定是不對的。程序猿也會要求不允許出現低級bug。尤其是這種團隊協作，自己的一點點不負責，很可能就給別人挖了一個大坑，這是非常忌諱的。題主也知道自己有錯在先，被批評這點就不多說了。

說說題主的主管，我個人也不喜歡脾氣火爆喜歡訓人的領導。但是如果真的是因為自己的低級錯誤，拖了團隊的後腿，被罵一頓也是無可厚非。題主也太玻璃心了，被說一頓就開始懷疑人生了？我們程序猿也只是努力做好自己的工作而已，不要動不動管我們叫大爺。

想想看我們公司這邊好像真的很少出現訓人的場景，如果出了事故，通常都是罰款，或者滾蛋（

結論：如果你的美術造化非常深厚，結論是你們主程傻逼。反之是你的不對。兩邊均有過錯，最主要原因是交流太少。我和題主的主程是一個毛病，特別傻逼，容忍不了太多小錯誤。

你說的對，一般的程序員都很好說話的。我見過最多也就罵罵自己的小弟。為一點小事跨部門罵人的第一次見。

摸頭，這事你沒錯。

作為程序，我也喜歡按自己那套命名規範來弄，因為資源統一命名和文件目錄對提高開發效率是有幫助的，而且有利於排查問題。

我們項目開始一般是自己制定一套，然後會跟美術組溝通，爭取得到一套兩個部門相對好的規範出來。

例如我開始想用英文來命名角色的資源，可是美術習慣了用拼音，最後也只能妥協了。

然後罵你那個主程連規範都沒定，憑什麼罵人。

退一萬步，就算定了規範，資源命名錯了，說一下不就得了唄，誰能保證不出錯！

說白了是其他人都已經忍了你很久了，終於有一個人忍不住跳出來了

程序員和美工處在完全極端的兩極，一般都覺得對方相當牛B，還可以一起吐槽產品經理啥的。

為了解決這種問題，我寫過一個小東西專門檢查命名是否規範然後生成映射代碼，不規範根本不讓你提交。美術可以方便自己檢查，程序也不需要找美術麻煩。這件事更讓我堅信好的工具和工作流程可以減少很多交互成本。

謝邀，題主恭喜你啊，你這是遇到了一個好程序啊！

要是換一個客客氣氣，百依百順的程序，表面上大家和和氣氣的，但是小問題逐漸積累成大問題了，最終還是損害了大家的利益啊！

你可以覺得他是U3D新兵，沒經驗，但是至少他在乎！可以看出，他是真真切切投入了心血，投入了感情在這個項目里的！他是從骨子裡想把這個項目做好，做屌！

這位程序員，也有不對的地方，劈頭蓋臉的，必然傷及他人自尊，破壞團隊士氣，可能還是個小年輕吧，或者是夢想還未完全熄滅的大叔。

程序員睡眠少，肝火旺，能體諒就體諒下吧。不過不建議慣著，否則你委屈自己，影響心情，要不得。練習下班後請他擼串，密集的腦力勞動後補充蛋白質最棒了，這個時候和他敞開了聊聊，或許會有收穫。

本來沒準備答的，畢竟我不是程序，然後看了第一贊同的那條「美術需要多做30%才會受答主這樣的程序歡迎」表示有一丟丟不爽，在評論里小小的評論了一下讓答主不要動不動就喊別人多做30%，問答主要是被別人要求多寫30%功能會不會爽。

居然跳出個人一開口就說我曾經當策劃的時候怎麼怎麼樣喜歡什麼什麼樣的程序員。

在坐的各位醒醒好嗎難道不是程序和美術一起吐槽策劃產品嗎？

有沒有搞清楚階級鬥爭的對象，自己人互相批判一番要不得呀XD

——————————————————————————

最後一句開玩笑的，路人策劃/產品別來找我撕逼謝謝(の￣︶￣)b

噢還有，我項目剛上線，最近比較閑所以才來答題的！！！！！謝謝所有好好對待美術的程序，我合作過的絕大多數程序都很nice，也有很多很好的朋友是做程序的，做人很nice好溝通的不管是程序和美術大家都會比較喜歡，而性格欠缺一點的肯定都有人吐槽的。

工作又不是結婚，能溝通就溝通，溝通不了就撕唄，不論對錯上來就開撕的，刪你代碼噢。

工作上不跟美術打交道，不過經常打球。首先，美術和程序絕對是平等的，不過美術的東西是給程序用的，所以有了個鏈的問題，他能馬上受到你的錯誤的影響，你
卻很少會馬上受到他的錯誤的影響。就是個工作鏈的問題導致程序會抱怨美術，同樣也會「抱怨」策劃！不過「抱怨」是有個度的，是雙方平等的溝通和交流，不尊
重別人是不太好。不過，任何人都難免會抱怨幾句，所以這些東西應該是公司制定一些原則，比如有什麼不滿應該主城和主美去溝通，而不是主城直接找美術，一不
小心就爆發了，這種情況你可以跟你們組長說，你受委屈了就找你的上司，我要是你上司，我當時就制止那個主程。

下面說你幾句，提交的東西別人就會用，不要出錯，出錯了別人一定會煩，不管有沒有說你，心裡總對你抱怨似乎是難免的。以後一定小心了。

最
後你問我們是不是覺得美術低一等？覺得自己牛的人多了去了，你也可以覺得他們低人一等，何必在乎，像我這種水貨還覺得程序同事水的要命（我是程序），不想
跟他們公事了，但是人家可能也是這樣想的。不過美術的話，我靠，跟我沒有矛盾沒有衝突，對那幫老爺們沒感覺呀，路人！不過妹子真的好，聊兩句就能高興一上
午。所以什麼高低，無非就是個人的看法罷了，確實有少數覺得美術不行啊之類的，絕少數！不過他們明明經常偷看美術的妹子，這幫人渣~~！

對了，你們美術的妹子是不是很多也看不上程序呀，整天一副屌絲樣，當然了我這種玉樹臨風的是例外！